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Preface 

The  original  objective  of  this  thesis  was  to  provide  the  engineers  at 
the  Aerospace  Guidance  and  Metrology  Center  (AGHC)  with  an  expert  system 
capable  of  interfacing  with  the  Automatic  Test  Equipment  (ATE)  used  to 
diagnose  faults  in  the  Dual  Miniature  Inertial  Navigation  System  (DMINS). 
In  accomplishing  this  objective,  this  effort  became  a  fascinating  study 
into  the  strengths  and  weaknesses  of  two  forms  of  diagnostic  reasoning: 
shallow  reasoning,  which  employs  compiled  knowledge  to  solve  a  problem, 
and  deep  reasoning,  which  solves  a  problem  by  constructing  a  model  of  the 
system  under  question.  The  result  of  this  study  is  the  Blended  Diagnostic 
System  (BDS),  a  system  which  employs  both  types  of  reasoning. 

BDS  was  developed  in  four  phases.  In  the  first  phase,  an  expert 
system  was  developed  in  a  traditional  AI  manner  that  employs  shallow 
reasoning.  In  the  second  phase,  a  model  of  the  system  was  constructed  and 
an  expert  system  was  developed  that  uses  deep  reasoning  to  diagnose  faults 
based  on  this  model.  In  the  third  phase,  the  two  systems  were  blended  into 
a  system  which  exploits  the  strengths  of  each  of  the  separate  systems. 
Finally,  the  fourth  phase  added  heuristics  to  ensure  that  BDS  always 
recommends  the  most  promising,  least  costly  tests  first,  and  leaves  the 
least-promising,  most  costly  tests  as  a  last  resort. 

The  success  of  a  thesis  is  a  measure  of  not  only  the  author,  but  of 
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Abstract 

Repair  v>t  the  Dual  Miniature  Inertial  Navigation  System  (DNINS),  a 
navigation  system  used  on  fast  attack  submarines,  is  the  responsibility  of 
the  Aerospace  Guidance  and  Metrology  Center  (AGMC)  located  at  Newark  AFB, 
OH.  Currently,  diagnostics  of  the  system  are  conducted  by  automatic  test 
equipment  (ATE).  Recent  plans  for  upgrades  of  the  computer  that  drives  the 
ATE  have  made  possible  the  integration  of  an  expert  system  with  the  ATE, 
thereby  increasing  system  reliability,  decreasing  test  times,  and 
improving  retention  of  site  knowledge. 

The  traditional  approach  to  developing  an  expert  system  is  to  use 
shallow  reasoning.  Shallow  reasoning,  which  encodes  knowledge  into  a  set 
of  IF-THEN  rules,  is  useful  for  incorporating  diagnostic  experience 
accumulated  with  a  unit  under  test  (Ul)T).\It  is  unable,  however,  to 
accommodate  situations  that  have  not  bpen  previously  encountered,  and  has 
questionable  applicability  system,  for  which  no  experience  is 

available'.^ 

Recent  research  in  expert  systems  has  emphasized  the  use  of  deep 
reasoning  for  diagnostics.  A  deep  reasoning  system  diagnoses  faults  by 
constructing  a  model  of  the  UUT,  relying  on  the  principle  of  locality  and 
causal  reasoning.  Deep  reasoning  is  suitable  for  a  new  system;  if  applied 
to  an  older  system,  however,  it  fails  to  take  advantage  of  the  lessons 
learned  by  repair-technicians. 

The  focus  of  this  thesis  is  the  development  of  BDS  (Blended 
Diagnostic  System),  a  diagnostic  system  which  emulates  a  human  technician 
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by  combining  shallow  and  deep  reasoning.  BDS  begins  by  trying  shallow 
techniques  derived  from  the  technician's  experience.  If  these  fail  to 
determine  the  fault,  BDS  resorts  to  deep  reasoning,  constructing  a  model 
of  a  sub-unit  of  the  UUT  suspected  to  be  faulty.  The  technician  using  BDS 
is  guided  around  the  model  by  heuristics  based  on  (a)  the  likelihood  of  a 
component's  being  the  cause  of  a  failure  and  (b)  the  expected  time 
required  to  test  the  component.  This  blending  of  shallow  reasoning  and 
heuristically-guided  deep  reasoning  extends  the  class  of  diagnosable 
faults  beyond  the  class  for  either  form  of  reasoning  alone,  and  reduces 
the  number  and  duration  of  tests  to  be  performed. 

A  prototype  of  BOS  has  been  constructed  for  the  ATE  used  on  the  Dual 
Miniature  Inertial  Navigation  System  (DMINS).  The  prototype  is  currently 
being  tested  at  Newark  Air  Force  Base,  OH. 
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A  OIAOIOSTIC  SYSTEM  BLENDING  DEEP  AND  SHALLOW  REASONING 

‘I 

I.  Introduction 


This  chapter  presents  an  overview  of  the  research  and  results  of 
this  thesis  effort.  Each  of  the  topics  in  this  chapter  is  discussed  in 
detail  in  the  corresponding  section  of  the  thesis. 
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Background 

Traditional  automatic  test  equipment  (ATE)  uses  a  go-chain  approach 
to  testing.  In  this  approach,  the  unit  under  test  (UUT)  undergoes  a 
series  of  predetermined  tests.  At  the  end  of  each  test,  the  results  are 
determined.  A  successful  test  will  allow  the  testing  sequence  to 
continue.  A  failure  will  result  in  the  termination  of  the  program  (3:37). 

Expert  systems  increase  the  effectiveness  of  the  ATE  by  including 
information  obtained  from  experienced  diagnosticians  and  by  providing  the 
technician  with  explanations  for  tests  (15:1).  A  literature  search 
reveals  that  most  expert  systems  for  ATE  and  fault  diagnosis  can  be 
placed  into  one  of  two  broad  categories:  systems  employing  shallow 
reasoning  and  systems  employing  deep  reasoning. 

Shallow  reasoning  encodes  empirical  knowledge  into  a  set  of  IF-THEN 
rules.  While  this  is  a  useful  method  of  incorporating  an  expert's 
experience  with  a  unit  under  test  (UUT),  it  is  unable  to  accommodate 
situations  that  have  not  been  previously  encountered  in  existing  systems, 
and  is  of  questionable  value  in  new  systems  where  no  experience  is 
available. 
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A  system  based  on  deep  reasoning  proceeds  from  an  understanding  of 
the  structure  and  function  of  the  UUT.  Common  approaches  to  deep 
reasoning  in  fault  diagnosis  are  reasoning  from  first  principles,  causal 
reasoning,  and  reasoning  from  the  principle  of  locality  (3:37).  Reasoning 
from  first  principles  emulates  the  ability  of  an  experienced  engineer  or 
technician  to  troubleshoot  an  unfamiliar  device  by  referring  to  the 
schematic  drawings  and  applying  appropriate  physical  lavs.  Causal 
reasoning  entails  an  understanding  of  the  mechanisms  and  pathways  by 
which  one  component  affects  another  in  a  specific  type  of  device.  The 
concept  of  locality  refers  to  components  that  are  connected  in  some 
manner,  e.g.  electrically  or  mechanically  (5:103-104).  Deep  reasoning  is 
appropriate  for  a  new  system;  when  applied  to  an  older  system,  however, 
it  does  not  take  advantage  of  the  lessons  learned  by  technicians  who  may 
have  repaired  the  system  for  some  years. 

Recently,  attempts  been  made  to  design  systems  incorporating  both 
deep  and  shallow  reasoning.  Examples  of  such  systems  are  PIS  (17:68-76), 
IN-ATE  (4:298-351),  and  IDM  (10:188-197).  FIS  assists  a  knowledge 
engineer  in  creating  a  computer  model  of  the  UUT  from  schematics;  it  then 
allows  the  addition  of  component  fault-probabilities  to  assist  in  the 
search  for  a  fault.  IN-ATE  assists  the  engineer  in  building  a  model  from 
block  diagrams,  then  recommends  the  best  test  to  conduct  next  based  on 
test  cost  or  fault-probability.  IDH  uses  two  knowledge  bases,  one 
containing  shallow  knowledge,  the  second  containing  deep  knowledge.  An 
executor-module  determines  which  of  the  knowledge  bases  will  work  on  the 
problem. 


Another  approach  to  the  combination  of  deep  and  shallow  reasoning 
in  diagnosis  is  to  emulate  the  human  technician.  The  Blended  Diagnostic 


System  (BDS)  was  developed  with  this  approach  in  mind. 

The  Blended  Diagnostic  System 

The  Blended  Diagnostic  System  (BDS)  uses  both  shallow  and  deep 
reasoning  to  emulate  the  way  a  human  technician  goes  about  diagnosing  a 
fault.  When  confronted  with  a  fault  a  technician  will  normally  (1) 
attempt  a  quick  fix  based  on  his  experience  with  such  a  failure  in  the 
past.  If  the  quick  fix  does  not  solve  the  problem  he  will  (2)  consult  the 
manual  to  determine  which  components  could  cause  such  a  problem  and  then 
(3)  test  the  suspect  components  in  a  order  that  is  based  on  which  one  is 
most  likely  to  be  at  fault. 

BDS  diagnoses  a  fault  in  a  corresponding  manner.  First,  BDS  will 
(1)  use  shallow  techniques  derived  from  the  technician's  experience  to 
imitate  the  technicians  initial  "quick  fix"  to  repair  the  fault.  If  such 
repair  is  not  successful,  BDS  will  (2)  resort  to  deep  reasoning, 
constructing  a  model  of  the  UUT,  similar  to  the  way  a  technician  resorts 
to  consulting  a  manual.  Finally,  BDS  will  (3)  use  heuristics  based  on  the 
likelihood  of  a  component's  being  the  cause  of  a  failure  (based  on  MTBF) 
and  the  cost  to  test  the  component  (based  on  time  required  to  test  the 
component);  these  heuristics  guide  the  technician  from  place  to  place  in 
the  model.  This  blending  of  shallow  reasoning  and  heuristically-guided 
deep  reasoning  extends  the  class  of  diagnosable  faults  beyond  those 
obtainable  from  either  form  of  reasoning  alone,  and  reduces  the  number 
and  duration  of  tests  to  be  performed. 
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The  Dual  Miniature  Inertial  navigation  Systea 

The  system  selected  to  test  the  performance  of  BDS  is  DHINS  (Dual 
Miniature  Inertial  Navigation  System).  First  introduced  in  1974,  DHINS  is 
an  inertial  navigation  system  used  on  fast  attack  submarines, 
oceanographic  survey  ships,  and  aircraft  carriers.  Repair  of  DHINS  is  the 
responsibility  of  the  Aerospace  Guidance  and  Metrology  Center  (AGMC) 
located  at  Newark  AFB,  OH.  Approximately  15  DHINS  inertial  measuring 
units  (IHU)  are  repaired  each  month  at  AGHC.  The  average  amount  of  time 
required  to  test  a  single  IHU  is  more  than  70  hours  (20:1369-1374). 

Currently,  fault  diagnosis  of  the  DHINS  IHU  is  conducted  by  ATE 
that  can  generate  any  of  62  error  messages  designed  to  aid  the  test 
technician  in  isolating  the  fault.  The  test  technician  is  responsible  for 
isolating  the  fault  to  one  or  more  of  the  38  shop  repairable  units  (SRU) 
that  make  up  the  IHU.  The  SRU  is  then  sent  to  a  clean  room  for  further 
diagnostics  and  repair. 
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BDS  was  developed  in  four  stages.  First,  an  expert  system  using  only 
shallow  reasoning  was  developed  in  the  traditional  manner.  Second,  an 
expert  system  was  developed  that  uses  deep  reasoning  to  construct  a  model 
of  a  portion  of  the  UUT.  Third,  the  shallow  and  deep  reasoning  systems 
were  blended.  Finally,  the  deep  reasoning  portion  of  the  system  was 
enhanced  with  heuristics  to  guide  the  technician  from  place  to  place  in 
the  model.  Each  of  the  phases  of  development  are  discussed  in  the 
reminder  of  this  chapter. 
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The  Shallow  Reasoning  Systea.  The  first  phase  was  to  develop  a 
traditional  expert  system  employing  shallow  reasoning.  The  structure  of 
the  systea  is  a  collection  of  empirical  associations  expressed  in  an 
IF-THEN  format.  This  system  was  developed  using  normal  knowledge 
engineering  techniques  (24:136).  In  particular,  the  knowledge  required  to 
define  the  system  was  elicited  in  sessions  with  a  technician  possessing 
14  years'  experience  on  the  DHINS  system. 

Decision  trees  were  constructed  for  each  of  the  62  possible  error 
messages  that  are  generated  by  the  ATE.  These  clarified  the  technician's 
method  of  reasoning,  proceeding  from  an  initial  error  message  to  location 
of  the  SRU  responsible  for  the  fault. 

The  information  from  the  decision  trees  was  encoded  in  S.l,  a 
commercial  expert  system  shell  developed  by  Teknowledge.  The  result  is  a 
system  with  142  production  rules  that  captures  relevant  knowledge 
possessed  by  Newark's  lead  technician.  The  system  is  capable  of  handling 
all  62  error  messages.  However,  as  with  all  shallow  reasoning  systems,  it 
can  only  isolate  faults  for  which  it  has  been  explicitly  programmed.  For 
this  reason,  emphasis  was  placed  on  maintainability  to  allow  the  system 
to  grow  as  new  situations  are  encountered. 

The  Deep  Reasoning  System.  In  the  second  phase,  a  system  was 
designed  that  employs  deep  reasoning.  The  method  was  developed  by  Randall 
Davis  (6:137-142)  and  is  discussed  in  the  S.l  User's  Guide  (23:3.15).  The 
scheme  uses  structural  diagnosis  to  construct  a  model  of  the  UUT  as 
needed,  and  diagnoses  faults  from  this  model. 

Structural  diagnosis  is  implemented  in  S.l  through  an  object 
oriented  scheme.  In  this  scheme,  the  knowledge  base  contains  information 
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about  each  component  in  the  structure,  as  veil  as  the  relationships  among 
the  components. 

The  approach  assumes  that  the  components  are  connected  and  that 
there  is  a  flow  of  information  from  one  component  to  another.  If  the 
output  from  a  structure  is  bad,  it  is  assumed  that  either  one  of  the 
inputs  is  bad,  or  the  component  itself  is  faulty.  If  one  of  the  inputs  to 
the  component  is  bad,  the  chain  of  components  is  followed  back  until  the 
faulty  component  is  found.  If  all  of  the  inputs  are  good,  then  the 
component,  assumed  to  be  at  fault,  is  diagnosed. 

Diagnosis  of  the  component  begins  by  examining  it  for  the  existence 
of  subcomponents.  If  subcomponents  exist,  a  model  of  the  component  is 
generated.  Components  are  created  only  when  needed;  efficiency  is  thus 
gained  by  minimizing  the  creation  of  instances.  Vhen  a  component  is  found 
to  have  no  subcomponents,  a  bad  output,  and  good  inputs,  the  component  is 
determined  to  be  faulty. 

The  necessary  structural  information  concerning  the  DHINS  IHU  was 
derived  from  the  organizational  level  technical  manual.  This  manual 
decomposes  the  system  into  ten  functional  categories,  each  of  which  is 
further  decomposed  into  the  shop  replaceable  units  (SRU)  which  are  of 
interest  to  the  technicians  at  Newark  (8).  Of  these  ten  functions,  the 
three  most  commonly  found  to  contain  the  source  of  the  fault  were  chosen 
to  be  modeled  for  the  prototype. 

The  resulting  system  can  diagnose  four  of  the  62  error  messages  from 
the  ATE.  This  system  is  successful  in  its  diagnosis;  however,  it  always 
initiates  a  full  point-by-point  search  for  the  fault  without  considering 
information  that,  while  unrelated  to  the  structure  of  the  IHU,  is 
relevant  to  the  diagnostic  process.  For  example,  the  deep  reasoning 
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systen  is  not  concerned  with  vhat  test  was  in  progress  when  the  error 
message  occurred,  even  though  this  information  is  valuable  to  the 
technician  when  isolating  the  fault. 

The  Blended  System.  In  the  third  phase,  deep  and  shallow  reasoning 
were  combined  to  create  a  blended  expert  system  that  exploits  the 
strengths  of  each.  This  system  emulates  a  human  technician:  shallow 
reasoning  is  used  first  to  try  and  find  a  "quick  fix";  if  this  is  not 
successful,  deep  reasoning  techniques  are  employed  for  a  more  thorough 
(and  time  consuming)  search. 

Adding  Heuristics  to  the  Model.  The  fourth  and  final  phase  was  to 
enhance  the  system  by  making  the  search  of  the  model  more  intelligent. 
This  was  done  by  assigning  two  attributes  to  each  of  the  components: 

RISK,  which  is  a  measure  of  the  likelihood  of  the  component's  being  at 
fault  based  on  MTBF  (mean  time  between  failure),  and  TEST-COST,  which  is 
a  measure  of  the  difficulty  to  test  the  component,  based  on  the  time  to 
test  (in  person-minutes).  These  attributes  ensure  that  the  most- 
promising,  least-costly  tests  are  performed  first  and  that  the  least- 
promising,  most-costly  tests  are  performed  only  as  a  last  resort. 

Conclusions 

By  blending  the  two  methods  of  reasoning  into  a  single  coherent 
system,  BDS  is  able  to  exploit  the  strengths  of  each  of  the  reasoning 
methods.  This  blending  of  shallow  and  heuristically-guided  deep  reasoning 
extends  the  class  of  diagnosable  faults  beyond  the  class  for  either  form 
of  reasoning  alone,  and  reduces  the  number  and  duration  of  tests  to  be 
performed  by  the  technician. 


The  renainder  of  this  thesis  will  give  the  reader  more  details  on 
the  theory,  process,  and  results  of  the  Blended  Diagnostic  System. 
Chapter  II  is  a  literature  review  of  shallow  and  deep  reasoning,  as  well 
as  a  survey  of  expert  systems  developed  for  ATE  and  fault  diagnosis. 
Chapter  III  describes  the  diagnostic  process  for  DHINS  at  Newark  AFB. 
Chapters  IV,  V,  and  VI  document  the  methodology  used  to  develop  the 
shallow  reasoning,  deep  reasoning,  and  blended  systems  respectively. 
Finally,  Chapter  VII  details  the  results  and  conclusions  from  this 
research,  and  provides  recommendations  for  future  work. 
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The  purpose  of  this  chapter  is  to  acquaint  the  reader  with  the 
current  state  of  the  art  in  expert  systems  applied  to  automatic  test 
equipment  (ATE).  This  is  accomplished  by  conducting  a  general  review  of 
artificial  intelligence,  expert  systems,  fault  diagnosis,  and  ATE 
followed  by  a  survey  of  current  expert  systems  applied  to  ATE. 

Artificial  Intelligence 

Although  the  field  of  Artificial  Intelligence  has  been  in  existence 
for  over  25  years,  there  is  still  no  single  uniformly  accepted  definition 
fo^  it.  Minsky  is  credited  with  the  most  accepted  definition  of 
artificial  intelligence  which  is  "the  science  of  making  machines  do 
things  that  would  require  intelligence  if  done  by  men"  (26:3). 

In  the  sixties,  scientists  attempted  to  create  artificial 
intelligence  by  building  general  purpose  programs  for  solving  broad 
classes  of  problems.  These  programs  met  with  only  limited  success.  It  was 
not  until  the  late  seventies  that  the  scientists  involved  realized  an 
intelligent  program  would  require  high-quality,  specific  knowledge  about 
a  narrowly  defined  problem  area  in  order  to  be  successful.  The  resulting 
special-purpose  computer  programs  were  called  expert  systems  (24:3-4). 

Expert  Systems 

An  expert  system  can  be  defined  as  "a  set  of  computer  programs  which 
emulates  human  expertise  by  applying  the  techniques  of  logical  inference 
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to  a  knovledtre  base"  (12:1).  Expert  systems  have  become  the  leading 
practical  application  of  artificial  intelligence  (12:1,  22:130). 

Expert  systems  are  an  attractive  alternative  to  conventional 
programming  languages  for  a  variety  of  reasons.  These  include  an  increase 
in  programming  productivity,  ease  of  understanding  by  non-programmers, 
extension  of  human  capabilities,  and  the  ability  to  handle  tasks  that  are 
unprogrammable  in  conventional  languages  (12:3-4). 

The  architecture  of  a  rule-based  expert  system  consists  of  a 
knowledge  base,  an  inference  engine,  and  a  user  interface.  The  knowledge 
base  contains  the  specific  knowledge  about  the  domain.  The  inference 
engine  contains  the  knowledge  required  for  problem-solving.  The  user 
interface  allows  the  user  to  access  the  system. 

The  knowledge  engineer  is  responsible  for  extracting  the  rules  from 
the  expert  and  building  the  knowledge  into  the  system.  Originally,  it  was 
necessary  for  the  knowledge  engineer  to  develop  all  parts  of  the  system. 
Today,  a  knowledge  engineer  may  choose  to  use  an  expert  system  shell 
which  will  contain  the  knowledge  representation  structure,  inference 
engine,  and  user  interface  (12:28).  Several  such  shells  are  available 
such  as  ART,  DUCK,  KEE,  KES,  N.l,  0FS5,  S.l  and  Goldworks  (24:107-109). 
The  three  shells  most  commonly  used  in  the  Air  Force  are  Goldworks,  N.l, 
and  S.l. 

Goldworks.  Goldworks  is  a  commercial  shell  developed  by  Gold  Hill 
Computers  and  is  written  in  Gold  Hill  Common  Lisp.  Goldworks  supports  the 
use  of  both  rules  and  frames.  Goldworks  was  designed  to  operate  on  a 
personal  computer  equipped  with  an  80386  processor.  However,  Goldworks 


can  be  operated  on  a  Z-248  (which  has  a  80286  processor)  by  installing  a 
card  kno%m  as  a  Hunmingboard.  The  Hummingboard  adds  an  80386  processor 
and  12  negabytes  of  memory. 


M.l.  M.l  is  a  commercial  shell  developed  by  Teknovledge  for 
rule-based  representation.  M.l  employs  a  backward  chaining  control  scheme 
and  an  English-like  language  syntax.  H.l  was  originally  implemented  in 
PROLOG  but  has  been  rehosted  in  C  to  increase  speed  of  execution.  M.l 
operates  on  a  IBM  PC  or  Z-248  (24:362). 

S. 1.  S.l  is  a  commercial  shell  also  developed  by  Teknowledge. 
Factual  knowledge  in  S.l  is  represented  in  frames,  heuristic  rules,  and 
procedural  control  blocks.  S.l  uses  backward  chaining  controlled  by  a 
procedural  command  language  for  its  inference  mechanism.  S.l  has  a 
built-in  certainty  handling  mechanism  and  an  explanation  capability.  S.l 
is  targeted  for  applications  such  as  diagnosis,  recommendation  and 
classification.  Originally  S.l  was  developed  to  be  run  on  Xerox 
workstations.  Teknowledge  released  a  PC  version  in  1986  (12:131;  24:365). 

Fault  Diagnosis 

In  order  to  understand  how  expert  systems  are  applied  to  fault 
diagnosis,  it  is  helpful  to  consider  how  a  human  diagnoses  a  fault.  The 
objective  of  fault  diagnosis  is  to  isolate  a  faulty  component  at  either 
the  Line  Replaceable  Unit  (LRU)  or  Shop  Replaceable  Unit  (SRU)  level. 

When  a  technician  performs  fault  diagnosis  he  employs  two  distinct  forms 
of  knowledge:  deep  and  shallow  (10:188). 

Deep  knowledge  is  based  on  first  principles,  axioms,  and  laws 
(11:30).  Shallow  knowledge  is  based  on  heuristics  and  experience.  As  a 


novice,  a  technician  relies  heavily  on  deep  knowledge  to  solve  a  problem. 
As  he  becomes  more  experienced,  he  compiles  this  deep  knowledge  into 
meaningful  chunks  of  easily  accessible  knowledge;  thus,  what  was  once 
deep  knowledge  becomes  shallow  knowledge.  As  an  expert,  the  technician 
will  consistently  use  this  shallow  knowledge,  resorting  to  deep  knowledge 
only  when  the  shallow  knowledge  fails  to  solve  the  problem. 

Reasoning  techniques  can  be  divided  into  similar  categories.  Deep 
reasoning  implies  an  understanding  of  the  device  being  diagnosed.  Common 
methods  of  deep  reasoning  used  in  fault  diagnosis  are  reasoning  from 
first  principles,  causal  reasoning,  and  reasoning  from  the  principle  of 
locality  (3:37).  Reasoning  from  first  principles  involves  reasoning  from 
an  understanding  of  the  structure  and  function  of  the  device  in  question. 
This  is  similar  to  the  ability  of  an  experienced  engineer  or  technician 
to  troubleshoot  an  unfamiliar  device  by  referring  to  schematic  drawings. 
Causal  reasoning  evolves  from  an  understanding  of  the  mechanisms  and 
pathways  by  which  one  component  affects  another  in  a  specific  type  of 
device.  The  concept  of  locality  refers  to  components  that  are  connected 
in  some  manner,  e.g.  electrical  or  mechanical  (5:103-104). 

Shallow  reasoning  uses  compiled  knowledge  based  on  heuristics  and 
experience.  Experience  in  fault  diagnosis  is  derived  from  past  repairs 
of  faulty  behavior  in  a  similar  unit.  Heuristics  are  the  rules-of-thumb 
that  an  expert  uses  to  reduce  an  unbounded  search  space  to  a  manageable 
size  (11:31). 

Traditional  expert  systems  employ  shallow  reasoning.  This  is 
accomplished  by  encoding  empirical  knowledge  into  a  set  of  IF-THEN  rules. 


12 


To  employ  deep  reasoning  an  expert  system  must  be  capable  of  generating  a 
model  of  the  system,  then  consulting  this  model.  This  model  can  be  a 
structural  model,  a  functional  model,  or  a  mathematical  model. 

Fault  diagnosis  is  the  most  widespread  industrial  application  of 
expert  systems  (12:226).  Expert  systems  applied  to  fault  diagnosis 
systems  in  electronics  require  a  relatively  modest  effort  for 
implementation  and  have  achieved  some  of  the  most  rapid  returns  in  terms 
of  the  ability  to  do  useful  work  (12:170).  However,  expert  systems  are 
not  the  most  common  method  of  diagnostic  assistance.  Long  before  expert 
systems  were  considered  for  diagnosing  faults  in  electronic  equipment, 
technicians  used  automatic  test  equipment  (ATE). 

Automatic  Test  Equipment 

The  concept  of  multipurpose  automatic  test  equipment  (ATE)  emerged 
in  the  mid-1950's  as  a  result  of  the  problems  in  maintenance  of  military 
electronics.  These  problems  included  complexity  of  the  equipment  to  be 
tested,  high  turnover  of  personnel,  long  test  times,  and  budgetary 
restrictions.  ATE  promised  to  speed  testing,  allow  for  operation  by 
low-skill  operators,  and  to  eliminate  maintenance  documents  (13:1). 

These  promises  have  not  been  completely  fulfilled.  Although  test 
times  decreased,  the  speeds  expected  were  not  achieved  because  of  the 
inability  of  the  units  under  test  to  respond  at  computer  speeds.  Reduced 
skill  requirements  were  realized,  but  this  was  offset  by  the  need  for  a 
test  programmer.  The  stack  of  trouble-shooting  documents  grew  smaller, 
but  was  soon  supplemented  by  ATE  documentation.  In  spite  of  these 
disappointments,  the  military  continues  to  support  ATE  because  mission 
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effectiveness  demands  fever  errors  and  shorter  test  times  than  is 


possible  with  manual  testing  methods.  In  addition,  ATE  provides  the 
capability  to  support  missions  that  would  otherwise  be  unrealizable. 
Although  commercial  applications  of  ATE  did  not  begin  until  the  early 
seventies,  they  have  increased  at  a  much  greater  pace  than  military 
applications  and  now  outnumber  them  (15:1-4). 

Traditional  ATE  use  a  go-chain  approach  to  testing.  In  this 
approach,  the  unit  under  test  (UUT)  undergoes  a  series  of  predetermined 
tests.  At  the  end  of  each  test,  the  results  are  determined.  A  successful 
test  will  allow  the  testing  sequence  to  continue.  A  failure  will  result 
in  the  termination  of  the  program  (3:37). 

This  type  of  testing  has  three  serious  limitations.  First,  it  can 
not  detect  multiple  faults.  Second,  the  sequence  of  testing  can  not  be 
dynamically  reordered.  Third,  it  can  only  reason  in  the  forward  direction 
(3:37-38). 

Applying  Expert  Systems  to  Automatic  Test  Equipment 

AI  is  a  fast-emerging  technology  in  the  ATE  community  (9:159). 
Demonstrated  successes  in  AI  applied  to  diagnosis  and  reasoning  (e.g. 
HYCIN  (24:283)  and  INTERNIST  (24:280))  have  contributed  to  AI's 
popularity  in  the  ATE  community  (7:129;  13:159).  The  ATE  community  is 
concerned  with  the  aspect  of  AI  that  develops  computers  capable  of 
problem  solving,  intuitive  reasoning,  and  learning  from  past  experiences 
(1:181;  13:159).  The  most  promising  areas  of  AI  applied  to  ATE  include 
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fault  isolation  and  test  sequence  optimization.  Application  of  expert 
systems  to  ATE  has  the  potential  to  improve  performance  by  up  to  30% 
(1:181). 

Expert  systems  promise  to  overcome  several  limitations  associated 
with  traditional  ATE.  Rules  can  continue  to  execute  regardless  of  the 
outcome  of  the  previous  test,  thus  allowing  for  the  detection  of  multiple 
faults.  Since  rules  have  no  precedence  of  execution,  dynamic  reordering 
of  the  test  sequence  is  possible.  Shells  that  allow  for  backward  as  well 
as  forward  chaining  allow  the  system  to  reason  from  symptoms  to  faults, 
or  to  postulate  a  fault  and  determine  if  the  symptoms  support  this 
hypothesis  (3:38). 

Additionally,  expert  systems  can  increase  the  effectiveness  of  ATE 
by  incorporating  the  technician's  experience  into  the  automatic 
diagnostic  process.  Another  advantage  expert  systems  offer  is  explanation 
facilities  that  can  increase  the  technician's  confidence  in  the  system  by 
explaining  the  need  for  a  particular  test. 

Current  Research 

The  topic  of  expert  systems  for  ATE  and  fault  diagnostics  of 
electronic  equipment  is  currently  being  explored  by  both  military  and 
commercial  researchers.  Several  systems  exist  and  are  in  varying  stages 
of  development.  A  survey  of  current  systems  is  presented  next. 

ACE.  The  Automated  Cable  Expertise  (ACE)  identifies  trouble  spots 
in  telephone  networks  and  recommends  appropriate  repair  and  maintenance 
without  human  intervention.  When  a  faulty  cable  is  detected,  ACE 
determines  the  type  of  maintenance  most  likely  to  be  effective  by 
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consulting  naintenance  reports,  knowledge  about  wire  centers,  and  network 
analysis  strategies.  Recofflmendations  are  then  stored  in  a  database  for 
access  by  the  cable  analyst.  ACE  was  developed  by  Bell  Laboratories  and 
is  implemented  in  0PS4  and  FRANZ  LISP  (24:253). 

ART-FUL.  ART-FUL  is  a  rule-based  diagnostics  system  developed  by 
RCA.  ART-FUL  attempts  to  overcome  the  inherent  limitations  of  automatic 
test  equipment  by  using  rule-based  diagnostics.  ART-FUL  allows  for 
forward  or  backward  reasoning  and  has  the  ability  to  detect  multiple 
faults.  ART-FUL  also  makes  the  dynamic  reordering  of  the  test  sequence 
possible.  ART-FUL  is  implemented  in  ART  and  runs  on  a  Symbolics  3670 
(3:37-43). 

ATEX.  ATEX  is  a  diagnostic  expert  system  designed  to  be  embedded  in 
an  ATE.  Its  purpose  is  to  assist  in  detecting  and  isolating  faulty 
modules  at  the  depot  level.  ATEX  identifies  and  ranks  faults  according  to 
their  likelihood.  ATEX  is  written  in  C  and  can  run  on  an  IBM  PC  or  be 
embedded  within  the  ATE  minicomputer.  ATEX  was  developed  by  Intelligent 
Electronics  Corporation  and  Tel  Aviv  University  (2:153-157). 

CEPS.  The  B-IB  Central  Integrated  Test  System  (CITS)  Expert 
Parameter  System  (CEPS)  combines  expert  system  technology,  conventional 
programming  and  a  large  data  base  to  provide  a  system  which  assists 
technicians  in  fault  diagnostics  on  the  Bl-B.  The  CEPS  prototype  was 
developed  in  S.l  by  Boeing  Military  Airplane  Company  (16:209). 

DART.  The  Diagnostic  Assistance  Reference  Tool  (DART)  assists  in 
diagnosing  faults  in  computer  hardware  systems.  DART  uses  information 
about  the  structure  and  expected  behavior  of  the  unit  to  identify  design 
flaws  in  new  devices.  DART  works  by  attempting  to  generate  a  proof  about 
the  cause  of  the  malfunction  using  an  inference  procedure  similar  to 


resolution  theorem  proving.  DART  was  developed  by  Stanford  University  and 
is  implemented  in  MRS  (Metalevel  Representation  System)  (24:250). 

FOREST .  FOREST  supplements  automatic  test  equipment  by  assisting  in 
fault  isolation  and  diagnosis.  FOREST  uses  the  engineer's  rules  of  thumb, 
circuit  diagrams,  and  general  electronic  trouble  shooting  principles. 
FOREST'S  capabilities  include  certainty  factors  and  an  explanation 
facility.  FOREST  is  implemented  in  PROLOG  and  was  developed  at  the 
University  of  Pennsylvania  in  cooperation  with  RCA  (24:256). 

I DM.  The  Integrated  Diagnostic  Model  (IDM)  uses  two  knowledge 
bases,  one  containing  shallow  knowledge,  the  second  containing  deep 
knowledge.  An  executor-module  determines  which  of  the  knowledge  bases  IDM 
will  use  to  work  on  the  problem.  IDM  is  implemented  in  Lisp  and  runs  on  a 
Symbolics  3600  Lisp  machine.  IDM  was  developed  by  Southwest  Research 
Institute  (10:189). 

In  addition  to  these  expert  systems,  research  is  underway  on  expert 
system  shells  for  automatic  test  equipment.  The  availability  of  these 
shells  increases  the  number  of  alternatives  available  to  the  knowledge 
engineer  charged  with  developing  an  expert  system  for  a  particular 
automatic  test  system.  Three  of  the  shells  under  development  are  FIS, 

LES,  and  IN-ATE. 

FIS.  The  Fault  Isolation  Shell  (FIS)  assists  in  developing  an 
expert  system  designed  to  aid  a  test  technician  in  isolating  faults  in 
electronic  equipment.  FIS  is  used  by  a  knowledge  engineer  to  create  a 
computer  model  of  the  UUT  from  schematics  and  block  diagrams.  FIS  uses 
this  model  internally  to  recommend  tests  and  analyze  results.  The 
approach  FIS  uses  to  diagnose  a  UUT  is  to  follow  causal  rules  to 
dynamically  obtain  all  possible  causes  of  the  unit  failure.  FIS  has  the 


ability  to  detect  multiple  faults.  The  methods  employed  by  FIS  make  it 
applicable  to  real-time  control  of  ATE.  FIS  was  originally  written  in 
Franz  Lisp  to  run  on  a  VAX  11/780  computer.  In  1986,  FIS  was  rehosted  in 
Lucid  Common  Lisp  and  now  runs  on  a  Sun  Workstation.  FIS  was  developed  at 
the  US  Naval  Research  Laboratory  (17:68-76). 

LES.  The  Lockheed  Expert  System  (LES)  is  a  framework  for  building 
expert  systems  designed  to  guide  less  experienced  maintenance  personnel 
in  fault  diagnosis  of  electronic  systems.  LES  captures  the  expert's 
knowledge  in  production  rules  and  supplements  this  with  knowledge  of  the 
structure,  function,  and  causal  relations  of  the  UUT.  LES  is  equipped 
with  an  explanation  facility  (14:414-435). 

IN-ATE.  The  INtelligent  ATE  (IN-ATE)  is  an  expert  system  shell 
designed  to  assist  in  the  construction  of  expert  systems  for  fault 
diagnosis.  It  uses  an  approach  known  as  logic  modeling  in  which  high 
level  block  diagrams  are  used  in  troubleshooting.  The  system  applies 
rules  supplied  by  an  expert  diagnostician  as  well  as  those  generated  from 
an  internal  model  to  isolate  faults  or  determine  the  next  test.  The 
system  was  developed  by  the  Automated  Reasoning  Corporation  and  is 
implemented  in  FRANZ  Lisp  (4:298-351;  24:342). 

Related  Theses 

There  have  been  several  theses  in  the  area  of  expert  systems  and  ATE 
previously  conducted  at  the  Air  Force  Institute  of  Technology.  In  1984, 
Ramsey  developed  an  expert  system  to  troubleshoot  a  power  supply  card  for 
the  F-15.  Difficulties  in  interfacing  the  automatic  test  equipment  to  the 
Lisp  Machine  prevented  the  system  from  ever  being  implemented  (19:IX-1). 


Ransey's  vork  was  continued  by  Estes  in  1966.  Estes  developed  a 
prototype  using  an  object-oriented  language  (FLAVORS)  on  the  Symbolics 
Lisp  machine.  Estes's  object  was  "to  develop  a  prototype  which  would 
generate  Abbreviated  Test  Language  for  All  Systems  (ATLAS)  programs." 

This  entailed  developing  a  "heuristic  approach  to  finding  a  near  optimal 
ordering  of  the  tests".  Although  Estes  greatly  narrowed  the  scope  of  his 
research  by  attempting  only  to  show  the  feasibility  of  the  approach  as 
opposed  to  any  implementation,  his  goals  were  not  realized.  Testing  was 
never  completed  and  no  studies  were  conducted  to  determine  the  economic 
benefits  of  an  Automatic  Test  Program  Generator  (ATPG)  (9:1-4). 

In  a  separate  1986  thesis,  Vunz  continued  Ramsey's  work  with  a 
functional  approach.  Vunz  developed  a  prototype  of  an  expert  system 
designed  to  diagnose  electronic  circuits.  The  prototype,  developed  in 
KEE,  was  successfully  tested  on  a  power  supply  but  had  several 
restrictions.  The  list  of  subcomponents  had  to  be  in  a  specified  order  to 
enable  testing  to  progress  properly  and  the  functional  rules  had  to  be 
written  in  Lisp  (25:VI-1). 

Indications  of  Future  Trends 

Current  studies  predict  AI  will  become  a  major  contributor  to  ATE  in 
the  near  future.  The  increasing  complexity  of  weapon  systems  and  the 
decrease  in  maintenance  manning  levels  make  the  application  of  expert 
systems  to  ATE  critical  for  the  support  of  weapon  systems  in  the 
twenty-first  century  (18:377). 


III.  The  Dual  Miniature  Inertial  Navigation  Systea 

The  system  selected  to  test  the  performance  of  the  Blended 
Diagnostic  System  is  the  Dual  Miniature  Inertial  Navigation  System 
(DHINS).  This  chapter  discusses  the  details  of  DHINS  and  its  test 
environment . 


Background  (20:1369-1374) 

The  Dual  Miniature  Inertial  Navigation  System,  first  introduced  in 
1974,  is  an  inertial  navigation  system  used  on  fast  attack  submarines, 
oceanographic  survey  ships,  and  aircraft  carriers.  DMINS  provides 
continuously  updated  attitude  (roll  and  pitch),  heading,  velocity  (north 
and  east),  and  position  (latitude  and  longitude)  data  to  the  other  ship 
subsystems.  The  system  consists  of  two  inertial  measuring  units  (IMUs), 
two  Blower  Assemblies,  two  Electrical  Equipment  Mounting  Bases,  and  a 
Navigation  Control  Console  (NCC). 

The  IMUs  contain  the  velocity  meters  and  gyroscopes  that  measure 
roll,  pitch,  heading,  and  velocity.  The  purpose  of  the  Blower  Assembly  is 
to  cool  the  IMU.  The  Electrical  Equipment  Mounting  Base  maintains  an 
accurate  alignment  between  the  unit  and  the  ship's  surface.  The  NCC 
provides  the  interface  between  the  INS  and  the  ships  computer. 

When  an  IMU  is  found  to  be  faulty  at  sea,  it  is  replaced  as  a  whole 
assembly.  The  faulty  IMU  is  then  sent  to  the  Aerospace  Guidance  and 
Metrology  Center  (AGMC)  at  Newark  AFB  for  repair.  On  average,  15  DHINS 
IMUs  are  repaired  each  month  at  AGMC.  The  average  amount  of  time  required 
to  test  a  single  IMU  is  more  than  70  hours. 


Figure  1.  Current  Test  Configuration  (20:1372). 


There  are  three  sets  of  diagnostic  tests  performed  on  the  DHINS  ATE 
at  Newark:  Node  A,  a  test  of  the  system  performance;  Node  B,  a  diagnostic 
check  to  ensure  that  the  operating  parameters  are  within  coarse  limits; 
and  Hode  C,  which  is  a  test  of  the  test  equipment  itself. 

When  an  IHU  arrives  at  AGHC,  it  initially  undergoes  Mode  B  testing 
to  detect  any  obvious  faults,  such  as  an  inoperative  power  supply.  If  the 
IHU  passes  Hode  B  tests,  it  proceeds  to  Mode  A  testing.  Mode  A  testing 
consists  of  a  series  of  five  tests  designed  to  determine  if  the  IMU  is 
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operating  vithin  specifications.  Appendix  A  is  a  list  and  description  of 
the  Mode  A  tests. 

If  a  fault  occurs  during  testing,  the  ATE  will  print  out  one  or  more 
of  62  possible  error  messages  (see  Appendix  B).  The  technician,  from 
experience  and  an  understanding  of  the  system,  uses  these  error  messages 
to  determine  a  course  of  action  that  will  isolate  the  fault  to  one  of  38 
shop  replaceable  units  (SRU)  contained  in  the  IMU.  When  the  faulty  SRU  is 
identified,  it  is  replaced  and  subsequently  sent  to  the  clean  room  for 
subcomponent  diagnosis  and  repair.  Next,  the  IHU  is  retested;  if  it 
passes,  it  is  sent  back  to  the  field. 

Due  to  the  lov  number  of  IHUs  tested  each  month,  and  the  length  of 
each  test,  it  requires  up  to  three  years  for  a  technician  to  acquire 
sufficient  knowledge  and  experience  to  effectively  diagnose  system 
failures.  As  experienced  engineers  and  technicians  leave,  overall  site 
knowledge  is  diminished.  As  a  result,  only  two  technicians  at  AGHC  are 
currently  considered  experts  and  are  in  high  demand  (21).  AGHC  has 
considered  use  of  an  expert  system  to  increase  the  effectiveness  of  the 
technician,  reverse  the  loss  of  overall  site  knowledge,  decrease  test 
times,  and  increase  test  reliability,  but  the  present  test  configuration 
will  not  support  integration  between  an  expert  system  and  the  test 
controller  (21). 

Recently,  AGHC  engineers  determined  that  the  IBM  1800  computer  must 
be  replaced  due  to  problems  in  maintainability  and  limited  memory  (64k). 
The  IBM  will  be  replaced  with  eight  Z-248s  connected  together  via  a  local 
area  network  (LAN);  one  Z-248  will  be  located  at  each  test  station,  a 
seventh  acting  as  an  overall  supervisor,  and  the  eighth  to  hold  a 
historical  database  (see  Figure  2).  This  configuration  increases  the  test 


Figure  2.  Planned  Test  Configuration  (20:1373). 


capability  of  AGNC,  allowing  them  to  test  up  to  six  IMUs  simultaneously. 
In  addition,  this  configuration  makes  it  possible  to  integrate  an  expert 
system  with  the  DNINS  ATE.  Since  no  expert  system  currently  exists  that 
is  capable  of  being  integrated  with  the  DNINS  ATE,  it  was  a  logical 
candidate  to  test  the  performance  of  the  Blended  Diagnostic  System. 

Assumptions 

To  ensure  that  the  problem  can  be  addressed  with  current  AI  tools, 
it  is  assumed  that  the  response  time  of  the  proposed  expert  system  is  not 
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critical.  That  is,  a  lapse  of  up  to  ten  ninutes  from  input  to  output  is 
acceptable  (as  implemented,  the  system  has  a  lapse  of  no  more  than  ten 
seconds) . 

To  reduce  risk  of  system  failure  due  to  network  problems,  it  is 
assumed  that  all  information  needed  by  the  expert  system  will  be  made 
available  on  the  expert  system's  host  computer.  The  expert  system  will 
not  be  involved  with  the  local  area  network  (LAN)  connecting  the  eight 
computers. 

The  system  engineer  at  AGHC,  ILt  Steven  Rasmussen,  has  agreed  to  the 
foregoing  assumptions. 

Scope 

The  expert  system  will  act  as  an  intelligent  assistant  to  the 
technician  for  purposes  of  identifying  faults  and  suggesting  further 
tests.  The  expert  system  developed  for  this  thesis  effort  will  run  off¬ 
line,  although  future  goals  will  be  to  integrate  the  expert  system  with 
the  test  controller  and  a  historical  database.  Integration  with  the  test 
controller  will  allow  parameters  to  be  passed  between  the  test  program 
and  the  expert  system  without  involving  the  technician.  Integration  with 
a  historical  database  will  provide  historical  data  to  be  used  to  identify 
component  configuration  (i.e.  which  gyros  and  velocity  meters  are 
contained  in  the  INU)  and  the  cause  of  previous  failures. 

The  expert  system  developed  in  this  thesis  effort  will  be  limited  to 
Mode  A  tests  only.  The  sequence  of  Node  A  tests  is  shown  in  Appendix  A. 
Future  projects  could  extend  the  expert  system  to  include  Mode  B  tests, 
or  even  include  testing  in  the  clean  room  at  the  subcomponent  level. 
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Developnent  of  the  local  area  network  (LAN)  and  the  historical 
database  are  not  a  part  of  this  thesis.  Both  the  LAN  and  historical 
database  will  be  implemented  independent  of  this  thesis  by  the  engineers 
at  AGMC. 
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IV.  The  Shallow  Reasoning  Systea 


This  chapter  documents  the  development  of  the  shallow  reasoning 
system,  an  expert  system  that  encodes  the  experiential  knowledge  of  the 
technician  into  a  set  of  IF-THEN  rules.  The  development  of  the  shallow 
reasoning  system  is  the  first  of  four  phases  of  development  of  the 
Blended  Diagnostic  System.  The  three  remaining  phases  (deep  reasoning, 
blended  system,  and  enhancements)  will  be  discussed  in  subsequent 
chapters. 


Hethodolof 


Before  beginning  development  of  the  shallow  reasoning  system,  an 
initial  assessment  of  the  problem  was  conducted  to  determine  if  an  expert 
system  was  "possible,  justified,  and  appropriate"  (24:127).  Development 
was  shown  to  be  possible  based  on  the  nature  of  the  task.  That  is,  the 
task  is  well  understood  and  requires  cognitive  skills  rather  than  common 
sense.  In  addition,  experts  exist,  can  articulate  their  methods,  and  are 
in  general  agreement.  Development  was  shown  to  be  justified  because  of 
the  continual  loss  of  expertise  at  AGMC  through  retirements  and  PCS 
moves.  Finally,  development  was  shown  to  be  appropriate  because  of  its 
practical  value,  manageable  size,  and  heuristic  nature. 

Actual  development  of  the  shallow  reasoning  system  was  accomplished 
based  on  a  process  described  by  Waterman  (24:136).  The  developmental 
effort  was  divided  into  six  phases:  identification,  tool  selection, 
conceptualization,  knowledge  acquisition,  implementation,  and  testing. 

The  results  of  each  phase  are  discussed  next. 
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Identification 


The  purpose  of  the  identification  phase  was  to  specify  the 
objectives  of  the  expert  system,  and  to  determine  the  important  features 
of  the  problem  including  the  scope,  required  resources,  and  the 
participants  in  the  development  process  (24:136). 

The  objective  of  the  expert  system,  given  any  one  of  the  error 
messages  from  Appendix  B,  is  to  assist  the  test  technician  in  isolating  a 
fault  in  the  IHU  to  one  of  the  38  individual  shop  replaceable  units  (SRU) 
listed  in  Appendix  C. 

Important  features  of  the  problem  were  identified  by  interviewing 
the  engineers  and  technicians  at  Newark  AFB  to  determine  the  current 
method  of  solving  the  problem  and  to  identify  what  aspects  of  the  problem 
could  best  benefit  from  AI  techniques.  In  addition,  an  extensive 
literature  search  was  conducted  to  identify  past  methods  of  solving 
related  problems  and  to  identify  existing  expert  systems  used  in 
diagnostics  and  automatic  testing.  The  results  of  the  literature  search 
are  cited  in  the  literature  review  in  Chapter  II.  The  scope,  presented  in 
Chapter  III,  was  derived  from  the  interviews  and  the  literature  search. 

Participants  required  were  identified  as  a  technician,  a  system 
engineer,  and  the  knowledge  engineer.  The  experts  were  identified  as 
Vally  Deskins  (primary  technician),  Jim  Neri  (alternate  technician),  and 
Steve  Rasmussen  (system  engineer).  I  assumed  the  role  of  knowledge 
engineer. 

Resources  required  for  this  project  were  identified  as  a  computer 
for  development  of  the  prototype,  funds  for  travel,  and  software  for 


development.  The  computer  was  obtained  from  AFIT/EN.  Funds  for  travel 
were  provided  by  AFVAL  and  AFLC.  Several  sources  offered  to  supply 
software  including  AFWAL  (Goldworks),  AFLC  (S.l  and  M.l),  and  the  Navy 
(FIS).  Several  shells  were  thus  available  during  tool  selection. 

Tool  Selection 

Although  Waterman  incorporates  tool  selection  into  the 
conceptualization  phase,  tool  selection  was  consider  important  enough  to 
merit  its  own  phase  during  this  project.  The  difficulty  in  selecting  a 
tool  for  developing  an  expert  system  comes  from  a  situation  known  as 
Davis's  Law  (24:142): 

"For  every  tool  there  is  a  task  perfectly  suited  to  it." 

The  opposite  is  not  true.  For  any  given  task  there  may  be  a  number  of 
tools  that  will  work,  or  none  that  will  work  at  all. 

Possibilities  for  tools  include  programming  languages,  commercial 
expert  system  shells,  or  developmental  research  shells.  For  this  project, 
it  was  decided  to  use  a  shell  in  order  to  take  advantage  of  the  powerful 
development  environment  associated  with  a  shell.  Shells  considered 
included  a  Navy  research  shell  (FIS),  as  well  as  three  commercial  shells 
commonly  used  in  Air  Force  projects  (Goldworks,  M.l,  and  S.l).  These 
tools  are  discussed  in  detail  in  the  literature  review  in  Chapter  II.  Of 
the  tools  considered,  S.l  was  selected  as  the  development  tool  for  the 
following  reasons:  (1)  AFLC  has  an  unrestricted  license  for  S.l;  (2)  S.l 
can  be  hosted  on  a  Z-248  without  any  additional  hardware;  and  (3)  Newark 
AFB  has  an  engineer  already  trained  in  S.l. 
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Conceptualization 

During  the  conceptualization  phase,  the  engineers  and  technicians  at 
Newark  AFB  were  interviewed  to  determine  what  concepts,  relations,  and 
control  mechanisms  are  required  to  describe  how  a  problem  in  the  domain 
is  solved. 

The  concepts  identified  in  this  phase  included  two  types  of 
diagnostic  reasoning  identified  in  the  literature  search:  deep  reasoning 
and  shallow  reasoning.  Shallow  reasoning,  which  encodes  empirical 
knowledge  into  a  set  of  IF-THEN  rules,  was  employed  in  development  of  the 
system  described  in  this  chapter.  Deep  reasoning,  which  requires  a 
knowledge  of  the  structure  of  the  unit  under  test  (UUT),  was  used  to 
develop  the  system  described  in  Chapter  V. 

The  relationship  identified  as  most  important  during  this  phase  was 
that  between  the  error  message  received  and  the  faulty  component 
responsible  for  that  message.  This  relationship  offers  the  explanation 
for  how  a  technician  diagnoses  a  fault:  an  error  message  is  generated  by 
the  ATE,  the  technician  interprets  the  message  and,  based  on  experience 
and  an  understanding  of  the  structure  of  the  system,  narrows  the 
possibilities  of  what  components  may  be  the  cause.  He  then  determines  a 
series  of  tests  that  will  isolate  the  fault  to  a  single  component. 

The  most  important  control  mechanism  identified  for  this  system  is 
the  ordering  of  the  tests  to  be  carried  out  by  the  technician.  The  order 
of  tests  affects  the  speed  of  the  isolation  of  the  fault.  If  components 
that  are  known  to  fail  often  are  tested  first,  the  time  required  to 
isolate  the  fault  will  normally  be  minimized. 
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Knowledge  Acquisition 

The  purpose  of  the  knowledge  acquisition  phase  (referred  to  as  the 
formalization  phase  by  Waterman  (24))  was  to  obtain  the  knowledge 
required  to  develop  the  expert  system  and  to  express  this  knowledge  in  a 
formal  framework.  For  the  shallow  reasoning  system,  this  entailed 
interviewing  expert  technicians  in  order  to  construct  decision  trees  for 
each  of  the  62  error  messages.  These  decision  trees  illustrate  the 
technician's  method  of  reasoning,  proceeding  from  an  initial  error 
message  to  the  location  of  the  SRU  responsible  for  the  fault. 

In  preparation  for  the  knowledge  acquisition  sessions,  decision 
trees  for  eight  common  error  messages  were  constructed.  These  decision 
trees  were  then  encoded  into  an  expert  system  prototype  for  the  purpose 
of  demonstrating  the  goal  of  the  knowledge  engineering  sessions  to  the 
expert  technician.  Also,  62  pages  were  prepared  for  sketching  the 
decision  trees,  each  blank  except  for  the  name  of  a  single  error  message 
at  the  top. 

Three  knowledge  acquisition  sessions  were  held  with  Jim  Neri,  a 
technician  with  14  years  of  experience  on  the  DMINS  system.  The  sessions 
were  scheduled  to  begin  at  7  PM  each  evening  in  Mr.  Neri's  workplace.  The 
location  was  chosen  in  order  to  keep  the  expert  in  his  own  domain,  and  in 
hopes  of  observing  any  details  which  may  have  seemed  of  little  importance 
to  the  expert,  such  as  logs,  notes,  or  reference  material.  The  time  was 
chosen  to  allow  Mr.  Neri  two  hours  from  the  start  of  his  shift  to  attend 
to  nightly  tasks  required  during  the  shift  change,  in  hopes  of  reducing 
interruptions. 
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The  first  session  began  with  a  demonstration  of  the  prototype,  and 
a  discussion  of  our  goals.  The  session,  which  lasted  3  1/2  hours, 
resulted  in  the  development  of  decision  trees  for  30  of  the  62  error 
messages.  For  the  most  part,  these  30  error  messages  were  the  easiest  for 
which  decision  trees  could  be  constructed,  either  because  they  were  rare 
error  messages  which  required  the  technician  to  seek  the  supervisor's 
assistance  early  in  the  decision  process,  or  because  they  were  common 
messages  with  a  simple  solution.  Attempts  were  made  to  construct 
decision  trees  for  error  messages  which  are  difficult  to  diagnose,  but 
with  no  success.  As  a  result  they  were  set  aside  for  a  later  session.  The 
limited  success  for  this  session  can  be  attributed  to  my  lack  of 
experience  as  a  interviewer,  as  well  as  Mr.  Neri's  lack  of  experience  as 
an  interviewee. 

The  following  day,  prior  to  Mr.  Neri's  arrival,  the  decision  trees 
from  the  first  session  were  coded,  and  the  code  was  subsequently  added  to 
the  existing  prototype.  Since  time  was  limited,  no  attention  was  paid 
during  coding  to  specifics,  such  as  ensuring  accuracy  of  the  explanation 
facility.  The  purpose  of  this  "rapid  prototyping"  was  to  determine  the 
accuracy  of  the  collected  decision  trees  and  to  reinforce  the  goals  of 
the  second  session. 

The  second  session,  which  lasted  about  2  hours,  began  with  a 
demonstration  of  the  prototype.  Notes  were  taken  as  to  how  this  prototype 
could  be  improved.  Due  to  the  experience  gained  by  both  parties  from  the 
previous  evening,  the  second  session  was  much  more  productive.  Hr.  Neri's 
answers  were  phrased  in  a  manner  more  easily  adapted  to  representation  by 
a  decision  tree.  The  session  resulted  in  construction  of  decision  trees 
for  all  but  three  of  the  most  difficult  error  messages. 


On  the  third  day  the  results  of  the  second  session  were  added  to 
the  prototype.  The  third  session,  which  lasted  one  hour,  began  with  a 


review  of  the  prototype  and  notation  of  required  changes.  Hr.  Neri 
brought  with  him  to  this  session  decision  trees  for  the  final  three  error 
messages.  The  decision  trees  were  of  such  quality  that  they  were 
implemented  without  significant  change. 

Figure  3  shows  the  decision  tree  for  one  of  the  62  error  messages 
(velocity  unreasonable).  The  method  by  which  the  decision  trees  were 
coded  into  S.l  is  described  in  the  next  section. 

Implementation 

The  implementation  phase,  which  overlapped  with  the  acquisition 
phase,  consisted  of  the  actual  coding  of  the  knowledge.  During  this 
phase,  the  information  from  the  decision  trees  was  encoded  in  S.l.  using 
the  four  basic  objects  in  S.l:  classes,  attributes,  control  blocks,  and 
rules. 

A  class  is  used  to  represent  an  object  in  the  domain.  Instances  of 
a  class  are  created  during  a  consultation  to  represent  individual  members 
of  the  set  described  by  the  class.  The  code  for  the  shallow  reasoning 
system  contains  a  single  class  called  IHU  for  inertial  measuring  unit. 

The  definition  of  this  class  is  shown  in  Figure  4. 

Attributes  in  S.l  are  used  to  represent  properties  of  classes  and 
relationships  between  classes.  During  a  consultation,  the  system 
determines  values  for  a  class's  attributes.  The  code  for  the  shallow 
reasoning  system  contains  117  attributes,  each  with  a  meaningful  name  to 
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Figure  3.  Decision  Tree  for  Velocity  Unreasonable. 
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END. DEFINE 

Figure  A.  S.l  Definition  of  Class  IHU. 


increase  readability  and  maintainability.  The  main  attributes  in  the  code 
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for  the  shallow  reasoning  system  are  ERROR. MESSAGE,  ACTION,  and  FAULT. 

ERROR. MESSAGE  determines  the  error  message  generated  by  the  ATE  by 
querying  the  user.  The  S.l  code  for  this  attribute  is  shown  in  Figure  5. 

I  Vhen  S.l  attempts  to  determine  this  attribute,  it  will  do  so  by  its  legal 

means,  (QUERY. USER} .  This  will  cause  the  prompt  "Vhat  error  message  is 
displayed"  to  appear  on  the  screen  along  with  a  list  of  the  legal  values, 

I  i.e.,  the  62  error  messages  contained  in  a  list  called  ERROR. MESSAGES. 

The  operator  can  then  select  the  appropriate  message  from  this  list. 

The  attribute  ACTION  uses  rules  to  determine  the  appropriate 
response  for  the  operator  to  take  in  response  to  an  error  message.  FAULT 
is  the  component  that  the  expert  system  determined  was  responsible  for 
the  error.  FAULT  allows  an  operator  to  query  S.l  about  previous  faults  in 
an  IMU  and  provides  a  "hook"  for  integration  of  a  historical  database. 
This  hook  will  make  it  possible  to  store  the  current  fault,  or  retrieve 
the  past  fault  of  an  IMU  to  assist  in  diagnosis. 
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DEFINE  ATTRIBUTE 
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: PROMPT 

"Vhat  error  message  is  displayed  ?" 

; TRANSLATION 

"the  displayed  IMU  Error  Message” 

END. DEFINE 

Figure  5.  S.l  Definition  of  the  Attribute  ERROR. MESSAGE. 


Control  blocks  in  S.l  control  the  forward  reasoning  flow  of  the 
program  by  allowing  the  programmer  to  specify  in  what  order  the 
attributes  should  be  determined.  The  top  level  control  block  for  this 
system  is  shown  in  Figure  6.  This  control  block,  which  is  invoked 
automatically  at  the  start  of  a  consultation,  creates  an  instance  of  the 
class  IMU,  then  determines  values  for  the  attributes  ERROR. MESSAGE  and 
ACTION.  Next  it  invokes  an  internal  control  block  which  will  display  the 
recommendations  to  the  technician.  Finally,  it  forces  the  attribute  FAULT 
to  be  determined.  Although  the  fault  will  normally  have  been  concluded  by 
this  point,  this  statement  will  ensure  that  if  no  value  could  be  found 
for  fault,  the  attribute  will  default  to  NOT. DETERMINED. 

Rules  in  S.l  are  used  to  express  heuristic  or  judgemental 
knowledge.  The  code  for  the  shallow  reasoning  system  contains  142  such 
rules.  These  rules  are  grouped  according  to  the  error  message  they  are 
attempting  to  troubleshoot.  This  increases  the  maintainability  of  the 
program  by  ensuring  that,  if  a  new  situation  is  encountered  at  Newark, 
required  changes  to  the  code  will  be  localized  to  the  area  of  the 
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DEFINE  CONTROL. BLOCK 

about. imu 

:: INVOCATION 

top. level 

::TRANSUTION 

"diagnose  faults  in  the  INU" 

J :BODY 

begin  vars  I:IHU; 

END. DEFINE 

display  spaces(25)  ! 

"THE  DMINS  FAULT  ADVISOR"! 
new.lineO; 

create. instance  IMU  called  I; 
determine  error.message[I] ; 
determine  action[I]; 
invoke  display. recommendations(I) ; 
determine  fault [I]; 
end 

Figure  6-  The  Top  Level  Control  Block. 

corresponding  error  message.  Appendix  D  contains  a  listing  of  the  set  of 
rules  that  pertain  to  the  error  message  velocity  unreasonable.  Figure  7 
shows  a  sample  rule  taken  from  this  set  of  rules.  When  this  rule  is 
fired,  the  technician  is  instructed  to  determine  if  the  platform  is 
level.  If  the  platform  is  level  the  technician  is  instructed  to  check  the 
velocity  meter. 


DEFINE  RULE 

Rule039 

: : APPLIED. TO 

I;  IMU 

:: PREMISE 

check. for. level. platform[I]  and 

azimuth.equal.zero{I] 

;  .-CONCLUSION 

check. veloci ty . me  ter  [  I ] 

Figure  7.  Sample  Rule  from  Shallow  Reasoning  System. 
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One  disadvantage  of  shallow  reasoning  systems  is  that  they  can  only 
diagnose  situations  for  which  they  have  been  programmed.  To  prevent 
degradation  in  the  event  an  uncoded  situation  is  encountered,  a  rule  was 
included  that  will  detect  this  situation  and  direct  the  technician  to  see 
the  shop  supervisor.  The  prompt  also  asks  that  the  engineering  section  be 
contacted  in  order  to  add  the  necessary  code  to  handle  this  situation 
should  it  reoccur.  This  rule  is  shown  in  Figure  8. 


DEFINE  RULE  ruleOOb 
:: APPLIED. TO  I:IMU 
::PREHISE  see. shop. supervisor(I] 

:: CONCLUSION  actionII]="this  is  a  difficult  problem  to  troubleshoot. 

Contact  the  shop  supervisor  for  further  assistance. 

Once  the  fault  has  been  determined,  contact  the 
engineering  section  so  this  program  can  be  updated  to 
include  the  new  information" 

END. DEFINE 

Figure  8.  A  Rule  to  Prevent  Rapid  Degradation. 

To  increase  the  technician's  confidence  in  the  expert  system, 
extensive  use  was  made  of  S.l's  explanation  facility.  This  allows  the 
technician  to  ask  why  S.l  is  requesting  that  a  specific  test  be 
performed.  For  example,  when  S.l  attempts  to  fire  rule039  (as  illustrated 
in  Figure  7)  the  operator  is  prompted  to  check  the  A  to  D  converter.  At 
this  point  the  operator  can  ask  why  this  is  necessary.  If  the  operator  is 
not  satisfied  with  the  answer  S.l  gives,  he  can  request  further 
explanation  by  asking  why  again.  S.l  will  backchain  through  the  rules  in 
an  attempt  to  explain  why  it  is  seeking  information  until  it  reaches  the 


top  goal  of  the  system.  Figure  9  is  an  excerpt  from  a  transcript  in  which 
the  operator  queried  S.l  for  the  ultimate  reason  for  checking  the  A  to  D 
converter. 

After  coding  was  complete,  an  attempt  was  made  to  increase  the 
efficiency  of  the  program  with  rule  categories.  By  categorizing  rules,  it 
is  possible  to  control  not  only  what  order  rules  are  fired  in,  but  also 
whether  they  will  be  fired  at  all.  It  was  reasoned  that  by  allowing  only 
the  rules  that  pertained  to  the  error  message  received  to  fire,  it  would 
speed  the  execution  of  the  consultation.  This  extra  control  feature  was 
implemented  by  assigning  all  142  rules  to  one  or  more  categories  based  on 
the  error  message(s)  to  which  the  rule  pertained.  Next,  the  legal  means 
by  which  all  of  the  attributes  could  be  determined  was  changed  to  force 
it  to  use  the  control  block  called  DETERMINE. ATTRIBUTE.  This 
determination  control  block  is  shown  in  Figure  10.  The  control  block 
restricts  S.l's  inference  engine  to  consider  only  the  rules  contained  in 
the  category  associated  with  the  error  message  received. 

The  resulting  program  was  tested  and  found  not  to  decrease  the 
execution  time.  It  is  postulated  that  the  overhead  associated  with  the 
rule  categories  canceled  any  savings  obtained  from  the  reduction  in  the 
number  of  rules  to  be  searched.  Because  the  addition  of  rule  categories 
added  complexity  without  any  apparent  increase  in  efficiency,  they  were 
removed.  As  the  program  grows,  it  may  be  worthwhile  to  implement  rule 
categories. 
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(6)  Check  the  A-D  converter  on  the  test  station. 

Is  the  platform  level  (azimuth  >  0)? 

m>  why 

I  asked  whether  the  platform  is  level  in  order  to  apply  rule039. 
Rule039  is  used  to  determine  whether  check  the  velocity  meter. 

rule039! 

If 

check  to  see  if  the  platform  is  level,  and 
it  is  not  true  that  the  platform  is  level, 
then 

check  the  velocity  meter. 

m>  why 

I  need  to  determine  whether  check  the  velocity  meter  in  order  to 
apply  ruleOAO.  Rule040  is  used  to  determine  whether  replace  the 
component  determined  faulty. 

rule040: 

If 

check  the  velocity  meter,  and 
the  velocity  meters  are  faulty, 
then 

replace  the  component  determined  faulty;  and 

the  fault  of  the  problem  is  corresponding. velocity. me  ter. 


m>  why 

I  need  to  determine  whether  replace  the  component  determined  faulty 
order  to  apply  rule004.  Rule004  is  used  to  determine  the 
recommendations  for  fixing  the  problem. 

rule004: 

If 

replace  the  component  determined  faulty, 
then 

the  recommendations  for  fixing  the  problem  is 

Recommend  that  the  <the  fault  of  the  problem>  be  replaced. 


m>  why 

I  need  to  determine  the  recommendations  for  fixing  the  problem  in 
order  to  diagnose  faults  in  the  INU  . 

This  is  the  top-level  goal  of  the  system. 


Figure  9.  A  Consultation  with  S.l's  Explanation  Facility. 
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DEFINE  CONTROL. BLOCK  determine. at  tribute 
; INVOCATION  determination 
:ARGUHENTS  a:attribute,  I:IMU 
tTRANSLATION  "Determine  the  appropriate  action" 

;BODY  begin 

case  error.message[I]  of 
no. input. 3. axes, 
no. input. az, 
no. input. pitch, 

no. input. roll:  seek  a(I]  by  rules 

whose. category. is  no. input; 
output . word . parity . fault , 
output .word. parity. cont, 
gyro . temp . normal , 

input. parity. fault:  seek  a{I]  by  rules 

whose. category. is  not. fault; 

pwr. interrupt , 

automatic. shutdown:  seek  a(I]  by  rules 

whose. category. is  power; 

xy . speed . con  t  rol , 

yz. speed. control: seek  a(I]  by  rules 

whose.category . is  speed; 
imu. major:  seek  a(I]  by  rules 

whose.category. is  major; 
velocity . unreasonable, 

vt. greater. than. 2. knots:  seek  a[I]  by  rules 

whose.category. is  velocity; 
excess. angle:  seek  afl]  by  rules 

whose.category. is  angle; 
servo. disable:  seek  a(I]  by  rules 

whose.category. is  servo; 
z.stab:  seek  a(I]  by  rules 

whose.category. is  stable; 
mux. decoder. dl. fault , 
cage. xy.dl. fault, 
cage. yz.dl. fault, 
gyro. star t . dl . faul t , 
gyro . run . dl . faul t , 
uyk . good . dl . faul t , 
inpu  t . pari ty . d 1 . faul t . mux04 , 
input . pari ty . no . 2 . dl . fault , 

output. word. parity. dl. fault. mux09:  seek  a[I]  by  rules 

whose.category. is  power. down; 
system. in. free. run:  seek  afl]  by  rules 

whose.category . is  free. run; 
imu. minor:  seek  all]  by  rules 

whose.category. is  other; 


Figure  10.  Control  Block  to  Implement  Rule  Categories. 
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x. gyro. torque. fault , 

y.  gyro. torque. fault, 

z.  gyro. torque. fault :  seek  a(I]  by  rules 

whose. category. is  torque; 

xvm.precounter. fault , 

yvm. precounter. fault:  seek  a[I]  by  rules 

whose. category. is  precounter; 
system. not. properly. caged:  seek  a[I]  by  rules 

whose. category. is  not. caged; 

gyro. hot, 

gyro. cold:  seek  a[I]  by  rules 

whose. category. is  gyro. temp; 
i.c. fault:  seek  a[I]  by  rules 

whose. category. is  ic. fault; 
rms. out. of .spec:  seek  a(I]  by  rules 

whose.category . is  out. of. spec; 
plat. stab. abort:  seek  a(I]  by  rules 

whose. category. is  platform; 

imu.o.load, 

imu.o. temp, 

dec . 0 . load . o . temp , 

dcc.o. temp, 

comp. tie. in. sw. on, 

i . c . f aul t . inhb . enab , 

seq .cnt.no. compare , 

i .c. data. loop. fault, 

i.c.fault.cont, 

in. parity. test. inhb. enab, 

ou  t . word . par . inhb . enab , 

major .reset . fault , 

minor. reset. fault, 

minor . fault . cont , 

both. vm. precounter . failure, 

vm. bite. failure, 

vt.vr. greater. than. 3. knots, 

minisins.vel.dif. exceeds. limit, 

minis ins . pos . di f . exceeds . lirai t , 

par  i  ty .  tes  t .  1 .  no .  go , 

parity. test. 2. no. go, 

parity. test. 3. no. go, 

put . intercom. test .no. go:  seek  a(I]  by  rules 

whose.category. is  rare.msg 


end 

end 


END. DEFINE 


Figure  10.  Control  Block  to  Implement  Rule  Categories  (Cont'd). 
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Testing 

The  shallow  reasoning  expert  system  has  a  set  of  known  entry  points 
(the  62  error  messages),  a  set  of  known  end  points  (the  38  SRUs),  and  a 
known  network  that  connects  the  entry  and  exit  points  (the  decision 
trees).  For  this  reason,  it  was  possible  to  test  the  system  exhaustively 
and  to  prove  that  it  accurately  reflects  the  information  captured  during 
the  knowledge  engineering  sessions. 

To  ensure  that  the  knowledge  captured  during  the  knowledge 
engineering  sessions  was  correct,  the  decision  trees  were  reviewed  by 
Newark's  other  technician  designated  as  expert,  Vally  Deskins.  Mr. 

Deskins  was  in  general  agreement  with  the  decision  trees,  thus  no  changes 
were  deemed  necessary. 

The  system  is  currently  under  test  in  the  Newark  shop  area. 
Technicians  compare  the  recommendations  and  conclusions  of  the  system 
against  actual  situations  and  suggest  modifications  for  improving  the 
system.  Each  consultation  by  a  technician  is  captured  on  a  script  for 
later  analysis. 

Results 

The  method  of  development  documented  in  this  chapter  resulted  in  an 
expert  system  based  on  shallow  reasoning  containing  142  rules.  This 
expert  system  successfully  handles  all  62  error  messages  generated  by  the 
ATE.  However,  as  with  all  shallow  reasoning  systems,  it  can  only  isolate 
faults  for  which  it  has  been  programmed  explicitly.  For  this  reason, 
emphasis  was  placed  on  maintainability  to  allow  the  system  to  grow  as  new 
situations  are  encountered. 
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It  should  be  noted  that  the  quality  of  the  resulting  expert  system 
is  directly  related  to  the  availability  of  technicians  experienced  on  the 
unit  for  which  the  expert  system  was  built.  In  the  case  of  DMINS,  the 
required  expertise  was  available.  Had  it  not  been  available,  the  shallow 
reasoning  system  would  have  limited  success. 


Conclusions 

Shallow  reasoning  encodes  empirical  knowledge  into  a  set  of  IF-THEN 
rules.  This  is  a  useful  method  of  incorporating  an  expert's  experience 
with  a  unit  under  test  (UUT).  The  quality  of  the  resulting  system, 

C  however,  is  dependent  on  the  availability  technicians  experienced  on  the 

unit  for  which  the  system  was  built. 

■ 
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This  chapter  documents  the  second  of  four  phases  in  the  development 


of  the  Blended  Diagnostic  System.  In  this  phase,  a  system  was  designed 
that  employs  deep  reasoning.  The  method  was  developed  by  Randall  Davis 
(6:137-142)  and  is  discussed  in  the  S.l  User's  Guide  (23:3.15-3.26).  The 
scheme  uses  structural  diagnosis  to  construct  a  model  of  the  UUT, 
refining  the  model  as  needed  to  locate  the  fault. 

S.l  Deep  Reasoning  Scheme 

As  was  discussed  in  Chapter  II,  a  diagnostic  system  based  on  deep 
reasoning  proceeds  from  an  understanding  of  the  structure  and  function  of 
the  UUT.  The  deep  reasoning  system  discussed  in  this  chapter  performs 
structural  diagnosis  through  the  principle  of  locality.  The  concept  of 
locality  refers  to  the  manner  in  which  components  are  connected. 

Structural  diagnosis  is  implemented  in  S.l  through  an  object 
oriented  scheme.  In  this  scheme,  the  knowledge  base  contains  information 
about  each  component  in  the  structure,  as  well  as  the  relationships  among 
the  components. 

The  approach  assumes  that  the  components  are  connected  and  that 
there  is  a  flow  of  information  from  one  component  to  another.  If  the 
output  from  a  structure  is  bad,  it  is  assumed  that  either  one  of  the 
inputs  is  bad,  or  the  component  itself  is  faulty.  If  one  of  the  inputs  to 
the  component  is  bad,  the  chain  of  components  is  followed  back  until  the 
faulty  component  is  found.  If  all  of  the  inputs  are  good,  then  the 
component,  assumed  to  be  at  fault,  is  diagnosed. 


Diagnosis  of  the  component  begins  by  examining  it  for  the  existence 


of  subcomponents.  If  subcomponents  exist,  a  model  of  the  component  is 
generated.  In  this  manner,  components  are  created  only  when  needed.  This 
increases  efficiency  by  minimizing  the  creation  of  instances.  Vhen  a 
component  is  found  to  have  no  subcomponents,  a  bad  output,  and  good 
inputs,  the  component  is  determined  to  be  faulty.  The  basic  algorithm  to 
diagnose  component (x)  is  shown  in  Figure  11. 


If  component (y)  is  a  bad  input  to  component (x) 
then  diagnose  component(y) ; 
else  if  component(x)  has  subcomponents 
then  build  the  subcomponents  and 

diagnose  the  first  subcomponent; 
else  component(x)  is  the  faulty  component. 


Figure  11.  Basic  Algorithm  for  Diagnosing  Faults. 


Knowledge  Acquisition 

The  objective  of  the  knowledge  acquisition  phase  for  the  deep 
reasoning  system  was  to  obtain  the  knowledge  required  to  construct  a  model 
of  the  DHINS  IHU.  The  necessary  structural  information  concerning  the 
DHINS  IHU  was  available  from  the  organizational-level  technical  manual 
(8).  This  manual  decomposes  the  system  into  ten  functional  categories, 
each  of  which  is  further  decomposed  into  the  shop  replaceable  units  (SRU) 
which  are  of  interest  to  the  technicians.  Of  these  ten  functions,  the 
three  most  commonly  found  to  contain  the  source  of  the  fault  were  chosen 
to  be  modeled  for  the  prototype.  The  functions  chosen  were  the  velocity 


■eter  function,  gyro  speed  control  function,  and  the  gyro  torque  function. 
In  addition,  it  was  necessary  to  consider  two  more  functions  at  the  top 
level,  the  timing  sequence  function  and  the  platform  torquing  function, 
since  the  chosen  functions  depend  on  their  output. 

Although  the  organizational  manual  contained  the  necessary 
structural  knowledge  for  the  DMINS  IHU,  it  was  not  possible  to  develop  a 
model  directly  from  this  manual  without  a  background  in  maintenance,  as 
well  as  a  deeper  understanding  of  the  components  of  the  system,  their 
purpose,  and  their  relationships.  For  this  reason,  a  knowledge  engineering 
session  was  held  with  ILt  Steve  Rasmussen,  the  designated  system  engineer, 
to  convert  the  schematics  from  the  manual  into  a  simple  model. 

The  knowledge  acquisition  was  accomplished  in  a  single  eight  hour 
session  (although  it  would  have  been  preferable  to  perform  the  acquisition 
over  a  series  of  shorter  sessions,  time  and  distance  constraints  made  this 
impossible).  This  session  took  place  in  a  conference  room  at  ILt 
Rasmussen's  workplace  to  allow  easy  access  to  necessary  reference 
materials. 

During  the  knowledge  acquisition  session,  the  components  of  the 
DHINS  IHU  were  discussed,  as  well  as  the  relationships  among  the 
components.  A  model  of  the  top  level  of  the  system  was  developed  by 
sketching  a  simple  block  diagram  on  the  blackboard.  From  this  model, 
inputs  and  outputs  of  the  chosen  functions  were  identified.  Each  of  these 
functions  were  subsequently  modeled  by  identifying  their  subcomponents, 
and  the  manner  in  which  they  were  connected.  As  each  new  component  was 
considered,  the  model  was  updated,  and  existing  portions  were  modified  to 
reflect  the  relationship  of  existing  components  to  the  added  component. 

The  resulting  top-level  model  of  the  DMINS  IHU  is  shown  in  Figure  12. 
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Models  depicting  further  decomposition  of  the  velocity  meter  function, 
gyro  speed  control  function,  and  gyro  torquing  function  are  shown  in 
Figures  13,  14,  and  15  respectively. 


Figure  12.  Top  Level  Model  of  the  DHINS  IHU. 


Figure  13.  Model  of  the  Velocity  Meter  Function. 
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Figure  lA.  Model  of  the  Gyro  Speed  Control  Function. 


Torque  Commands  -7 


Gyro  Field  Return 


Figure  15.  Model  of  the  Gyro  Torquing  Function. 


Hov  Knowledge  Acquisition  Differed  For  The  Two  Types  of  Reasoning 

The  goal  of  the  knowledge  acquisition  phase  for  both  the  deep 
reasoning  and  shallow  reasoning  system  was  to  gather  the  knowledge 
required  to  develop  the  system.  However,  the  two  phases  differed  in  that 
the  source  of  the  knowledge  for  the  shallow  reasoning  system  was  an 
expert,  whereas  the  source  of  the  knowledge  for  the  deep  reasoning  system 
was  a  manual,  with  an  expert  acting  only  as  a  translator. 

Difficulties  during  the  two  sessions  were  similar.  In  both  cases, 
there  was  a  tendency  for  the  experts  to  go  into  more  detail  than  was 
necessary  to  build  the  system.  Since  time  was  constrained  in  both  cases, 
it  was  necessary  as  a  knowledge  engineer  to  ensure  that  discussions 
remained  relevant.  This  entailed  a  trade-off  between  acting  as  an 
interrogator  to  receive  the  most  information  in  the  least  amount  of  time, 
risking  damage  to  the  relationship  with  the  expert,  and  allowing  the 
expert  to  continue,  in  order  to  let  him  clarify  his  ideas,  meanwhile 
improving  the  rapport  with  the  expert. 

The  technical  manual  was  a  valuable  asset  in  the  case  of  the  deep 
reasoning  system  in  that  it  served  as  a  point  of  focus  for  the  interview. 
No  such  focal  point  existed  for  the  shallow  reasoning  system,  except  for 
the  error  message  written  at  the  top  of  the  page  of  each  decision  tree. 

In  conclusion,  the  existence  of  a  document  as  the  source  of 
knowledge  in  the  deep  reasoning  system  did  not  eliminate  the  need  for  an 
expert,  since  interpretation  of  the  manual  was  necessary.  Consequently, 
many  of  the  problems  associated  with  interviewing  an  expert  remained. 
However,  the  manual  provided  a  focal  point  for  discussions,  and  was 
employed  as  a  convenient  return  point  when  the  discussions  drifted  into  an 
unproductive  state. 
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Prograa  Operation 

The  best  way  to  understand  the  program  is  to  consider  how  it 
operates.  When  a  consultation  begins,  the  top  level  control  block  is 
invoked.  This  block,  shown  in  Figure  16,  creates  an  instance  of  the  class 
IHU,  assigns  it  a  name,  and  declares  that  it  has  subcomponents.  Next  the 
program  determines  the  error  message  by  querying  the  user.  If  the  error 
message  is  one  of  the  four  that  corresponds  to  the  functions  in  this 
model,  the  control  block  DEEP. DIAGNOSE,  shown  in  Figure  17,  is  invoked 
with  IHU  as  an  argument.  Otherwise,  the  user  is  notified  and  the  program 
terminates . 


DEFINE  CONTROL. BLOCK  DIAGNOSE. I MU. FAULT 

: : INVOCATION  top . level 

: ‘.TRANSLATION  "determine  the  fault  in  the  IMU" 

! tBODY 
begin 

vars  I: IHU; 

create. instance  imu  called  I  with 
begin 

name.of(IJ  .  "IMU"; 
has . subcomponent ( I ] ; 
end; 

determine  error.message[I] ; 

if  error .message! I]  is  in  {velocity. unreasonable, 

vt. greater. than. 2. knots, 
xy . speed . con  t  rol , 
yz. speed. control} 

then  invoke  deep.diagnose(I) 

else  display  new.lineO  !  "This  error  message  has  not  been  "! 
"included  in  the  model." 

end; 

END. DEFINE 


Figure  16.  Top  Level  Control  Block  for  Deep  Reasoning. 
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DEFINE  CONTROL. BLOCK  DEEP . DIAGNOSE 

:: INVOCATION  internal 

: : ARGUMENTS  COMPONENT : i mu . componen  t 

:: TRANSLATION  "diagnose  component  to  determine"! 

"fault" 

;;BODY 

begin 

determine  bad. input (COMPONENT ] ; 
if  bad. input [COMPONENT]  definite 
then  begin 

if  exists(CONPONENTl:imu. component  | 

connected. to(CONPONENTl, COMPONENT]  . 

bad. input [COMPONENT]) 

then  invoke  deep.diagnose(COMPONENTl) 

end 

else  begin 

if  has. subcomponent [COMPONENT] 
then  begin 

invoke  build. subcomponent (COMPONENT) ; 
if  exists  (COMPONENT!: i mu. component  I 
same . ou  t  pu  t . as [ COMPONENT , COMPONENT! j ) 
then  begin 

invoke  deep.diagnose(COMPONENT!); 
end 
end 

else  display  nev.lineO  !  nev.Iine()! 

"The  fault  was  found  to  be  " 

!  instance. trans(component)!"."; 
end 

end; 

END. DEFINE 


Figure  17.  The  DEEP . DIAGNOSE  Control  Block. 


The  DEEP . DIAGNOSE  control  block  implements  the  algorithm  shown  in 
Figure  11.  It  has  four  key  attributes: 


1.  CONNECTED. TO [COMPONENTl, COMPONENT!]  =  N.  This  attribute  indicates  that 
the  output  of  componentl  is  the  Nth  input  of  component!.  This  is  the 
attribute  that  allows  the  system  to  chain  through  the  network  of 
components. 
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2.  HAS. SUBCOMPONENT I COMPONENT].  This  is  a  boolean  attribute  that  is  true 
if  component  can  be  decomposed  into  subcomponents.  The  value  for  this 
attribute  is  determined  at  the  time  the  component  is  created,  using 
information  from  the  control  blocks  which  describe  the  component. 

3.  BAD. INPUT I  COMPONENT]  =  M.  The  value  (M)  of  this  attribute  is  the 
integer  associated  with  the  CONNECTED. TO  attribute  for  the  pair 
consisting  of  the  component  responsible  for  the  bad  input  and  the 
component  under  diagnosis.  The  value  of  BAD. INPUT  is  determined  by 
trying  rules. 

4.  SAME. OUTPUT. AS I C0MP0NENT1,C0MP0NENT2].  This  attribute  is  true  if 
componentl  and  component2  have  the  same  output.  This  attribute  provides 
the  mechanism  by  which  diagnosis  continues  after  the  subcomponents  of  a 
component  under  diagnosis  have  been  constructed.  Specifically,  if 
componentl  has  a  bad  output,  good  inputs,  and  subcomponents,  the 
subcomponents  of  componentl  will  be  instantiated  and  diagnosis  will 
begin  with  component2.  At  that  time  it  will  be  known  that  component2, 
like  componentl,  has  a  bad  output. 

Deep  diagnosis  begins  by  determining  if  the  component  under 
diagnosis  has  any  bad  inputs.  This  is  done  by  firing  the  rule  shown  in 
Figure  18.  This  rule  requires  an  additional  attribute,  OUTPUT . TEST . OK , 
which  prompts  the  user  to  test  the  output  of  the  component  that  is  the 
input  to  the  component  under  diagnosis.  This  is  a  very  powerful  rule.  In 
fact,  it  is  the  only  rule  required  to  perform  deep  diagnosis. 


DEFINE  RULE 

RULE. 201 

:: APPLIED. TO 

COMPONENT : i mu . componen  t 

:  .-PREMISE 

already . exis t ing(C0MP0NENTl : imu . component  | 
determined? ( connected . to [ COMPONENTl , COMPONENT  1 ) 
and  connected. to  I COMPONENTl, COMPONENT)  known 
and  output. test. ok[C0MP0NENTl]  thought. not) 

:: CONCLUSION 

END. DEFINE 

bad.  input  {COMPONENT] 

connec  t  ed . to { COMPONENTl , COMPONENT ] 

Figure  18.  Rule  to  Determine  Bad  Inputs  to  a  Component. 


All  inputs  to  the  component  are  tested  with  this  rule  until  a  bad 
input  is  found,  or  all  of  the  inputs  have  been  found  to  be  good.  If  a  bad 
input  is  found,  DEEP. DIAGNOSE  will  be  invoked  with  the  component  whose 
output  is  bad  as  the  argument.  This  recursion  will  continue  until  a 
component  is  found  with  no  bad  inputs. 

When  all  of  the  inputs  to  a  component  are  found  to  be  good,  the 
component  is  checked  for  subcomponents.  If  the  component  has 
subcomponents,  the  program  invokes  the  control  block  called 
BUILD. SUBCOMPONENTS,  shown  in  Figure  19.  BUILD. SUBCOMPONENTS  consists  of  a 
single  case  statement  that  will  invoke  the  control  block  that  contains  the 
structural  information  required  to  create  a  model  of  the  component  under 
diagnosis. 

The  deep  reasoning  program  has  five  control  blocks  containing 
structural  knowledge:  one  each  for  the  IMU,  Velocity  Meter  Function,  and 
Gyro  Torque  Function,  and  two  control  blocks  for  the  Gyro  Speed  Control 
Function.  The  need  for  the  two  blocks  for  the  Gyro  Speed  Control  Function 
stems  from  the  fact  that  this  algorithm  is  restricted  to  single-output 
components.  Multiple-output  components  must  be  modeled  by  creating 


DEFINE  CONTROL. BLOCK 
:: INVOCATION 
:: ARGUMENTS 
:  -.TRANSLATION 


BUILD. SUBCOMPONENTS 
internal 

COMPONENT: i mu. component 

"build  the  logical  subcomponent"! 

"of  the  system" 


:  :BODY 
begin 

vars  I:imu, 

GTF : gy ro . torque . func  t ion , 
GSCFO:gyro.speed.control. function. out put , 
GSCFE : gy ro . speed . con  t  rol . func  t ion . error , 
VMF: velocity. me ter. function; 


case  name. of [COMPONENT]  of 
"IMU":  begin 

if  exists  I:IMU 

then  invoke  build. imufl) ; 

end; 

"gyro  torquing":  begin 

if  exists  GTF:gyro. torque. function 

then  invoke  build. gyro. torque. function(GTF) ; 

end; 

"gyro  speed";  begin 

if  exists 

GSCFO ; gy r 0 . speed . control . func  t i on . ou  t  pu  t 

then  invoke  build. speed. control. output(GSCFO) ; 

end; 

"speed  error":  begin  if  exists 

GSCFE : gy ro . speed . con  t  rol . func  t i on . error 
then  invoke  build. speed. error (GSCFE) ; 
end; 

"velocity";  begin  if  exists  VMF: velocity .meter . function 
then  invoke  build. velocity. function(VMF) ; 
end 
end; 
end; 

END. DEFINE 


Figure  19.  The  BUILD. SUBCOMPONENTS  Control  Block. 


multiple  instances  of  the  component,  one  for  each  separate  output.  The 
control  block  containing  the  structural  information  for  the  Velocity  Meter 
Function  is  shown  in  Figure  20. 


DEFINE  CONTROL. BLOCK 
:: INVOCATION 
:: ARGUMENTS 
TRANSLATION 

:;BODY 
begin 

vars  T.E: test .equipment , 

X. VH:x. velocity .meter , 

Y. VM:y. velocity. meter , 

P: power. distribution, 

F: frequency. standard; 

display  nev.line()!  nev.line()!  "The  fault  has  been  isolated"! 
"  to  the  velocity  meter  function.  The  subcomponents  of  the"! 

"  velocity  meter  function  will  be  constructed."; 

create. instance  test .equipment  called  T.E  with 
same.output .as(VMF,T.E] ; 

if  exists  PTF:platform. torquing. function 
then  create. instance  x. velocity .meter  called  X.VH  with 
begin 

connected. toIX.VMjT.EJ  =  1; 
connected. toIPTFjX.VM]  =  1; 
end; 

if  exists  PTF: platform. torquing. function 
then  create. instance  y. velocity .meter  called  Y.VM  with 
begin 

connected. toIY.VMjT.EJ  =  2; 
connected. tojPTFjY.VMJ  =  1; 
end; 

create. instance  frequency .standard  called  F  with 
begin 

connected. tolF,X.VMJ  *  2; 
connected. to[F,Y.VMJ  *  2; 
end; 

create. instance  power .distribution  called  P  with 
begin 

connected. tolP,X.VMJ  =  3; 
connected. tojPfY.VMJ  ■  3; 
end; 
end; 

END. DEFINE 


BUILD . VELOCITY . FUNCTION 
internal 

VMF; velocity. meter . function 
"build  the  logical  subcomponent"! 
"of  the  velocity  meter  function" 


Figure  20.  Structural  Information  for  the  Velocity  Meter  Function. 
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After  the  subcomponents  of  a  component  have  been  built, 

DEEP . DIAGNOSE  is  invoked  with  the  argument  set  equal  to  the  component 
which  has  the  same  output  as  the  parent  component.  This  recursive 
diagnosis  continues  until  a  component  is  found  that  has  a  bad  output,  no 
bad  inputs  and  no  subcomponents.  At  this  point  it  is  reasoned  that  this 
component  is  the  fault  in  the  system. 

Enhancements 

As  stated  earlier,  the  rule  shown  in  Figure  18  is  the  only  rule 
required  to  make  the  program  run.  However,  rules  and  attributes  were  added 
to  tailor  the  algorithm  to  DMINS.  For  example,  the  attribute  ERROR. MESSAGE 
and  rules  202  through  205,  shown  in  Figure  21,  were  added  to  provide  entry 
into  the  program  directly  from  the  error  message.  When  the  error  message 
is  determined,  the  program  will  automatically  mark  the  output  of  the 
functions  as  good  or  bad,  depending  on  the  relationship  between  the  error 
message  and  the  function. 

Additional  rules  and  attributes  were  included  to  increase  the 
readability  of  the  prompts.  For  example,  the  addition  of  rule207,  rule208, 
and  the  attribute  LEVEL. PLATFORM,  shown  in  Figure  22,  changed  the  prompt 
from  "Is  the  output  of  the  platform  torquing  function  good?"  to  "Is  the 
platform  level?".  The  latter  prompt  is  much  more  meaningful  to  the 
I  technician. 
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DEFINE  ATTRIBUTE 
DEFINED. ON 
::TYPE 

:  .-MULTIVALUED 
:: LEGAL. VALUES 
:: LEGAL. MEANS 
: : DETERMINATION . MEANS 
: : PROMPT 
:: TRANSLATION 
END. DEFINE 


ERROR. MESSAGE 

I:IMU 

text 

false 

error. messages 
{query. user} 

(query. user) 

”Uhat  error  message  is  displayed?" 
"the  displayed  IMU  Error  Message" 


DEFINE  RULE 
: : APPLIED. TO 
:: PREMISE 


: : CONCLUSION 
END. DEFINE 


RULE. 202 

veloc 1 ty. me ter. function 
a’  "f 3dy.existing(I:imu| 

error.-'es  lagefll  is  in  (velocity. unreasonable, 

vt. greater. than. 2. knots) ) 
ou  put. test. ok (velocity. me ter. functionj<-1.0> 


DEFINE  RULE 
: : APPLIED. TO 
;; PREMISE 


:: CONCLUSION 
END. DEFINE 


RULE. 203 

gyro.speed.control. f unction. error 
already.existing(I: imu| 

error .message[IJ  is  in  (velocity .unreasonable, 

vt. greater. than. 2. knots) ) 
output . test .ok(gyro. speed. control. function. error] 


DEFINE  RULE 
: : APPLIED. TO 
PREMISE 


; ; CONCLUSION 
END. DEFINE 


RULE. 204 

velocity. me ter .function 
already. existing(I: imu| 
error .message] I]  is  in  (xy. speed. control, 

yz. speed. control) ) 

output. test . oktvelocity. meter . function) 


DEFINE  RULE 
APPLIED. TO 
:: PREMISE 


;; CONCLUSION 
END. DEFINE 


RULE. 205 

gyro.speed.control. f unction. error 

already.existing(I: imu| 

error. message[I]  is  in  (xy. speed. control, 

yz. speed. control) ) 

output . tes  t . okl gyro . speed . control . f unc  t ion . error  j  <-l . 0> 


Figure  21.  The  Attribute  and  Rules  Required  to  Initiate 
Diagnosis  from  an  Error  Message. 
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DEFINE  ATTRIBUTE 

LEVEL. PLATFORM 

: : DEFINED. ON 

platform. torquing. function 

: ;TYPE 

boolean 

; ; MULTIVALUED 

false 

: : LEGAL. MEANS 

{query .user) 

DETERMINATION. 

MEANS  {query. user) 

: : PROMPT 

"Is  the  platform  level?" 

TRANSLATION 

"the  platform  is  level" 

END. DEFINE 

DEFINE  RULE 

RULE. 207 

APPLIED. TO 

platform. torquing. function 

:: PREMISE 

level. platform(platform. torquing. function] 

; : CONCLUSION 

output . test .okjplatform. torquing. function] 

END. DEFINE 

DEFINE  RULE 

RULE. 208 

APPLIED. TO 

platform. torquing. function 

:: PREMISE 

not  level. platform(platform. torquing. function] 

; : CONCLUSION 

output . test .ok] platform. torquing. function]<-l .0> 

END. DEFINE 

Figure  22.  Attribute  and  Rules  Added  to  Improve  Prompts. 


Results 


The  resulting  system  can  diagnose  the  following  four  of  the  62  error 
messages  from  the  ATE;  xy  speed  control,  yz  speed  control,  velocity 
unreasonable,  and  vt  greater  than  2  knots.  This  system  is  successful  in 
its  diagnosis;  however,  it  always  initiates  a  full  point-by-point  search 
for  the  fault  without  considering  information  that,  while  unrelated  to  the 
structure  of  the  IMU,  is  relevant  to  the  diagnostic  process.  For  example, 
the  deep-reasoning  system  does  not  concern  itself  with  what  test  was  in 
progress  when  the  error  message  occurred,  even  though  the  decision  tree  in 
Figure  3  from  Chapter  IV  shows  that  this  information  is  valuable  to  the 
technician. 
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Another  point  to  note  is  that  the  system  makes  no  use  of  information 


based  on  the  technician's  experience.  For  example,  based  on  the 
heuristics  from  the  shallow  reasoning  system,  a  YZ  speed  control  error 
message,  unlike  an  XY  speed  control  error  message,  is  not  an  indication 
of  a  fault  unless  it  has  occurred  more  than  twice.  The  deep  reasoning 
system  treats  the  two  error  messages  identically,  initiating  a  full  point 
to  point  search,  perhaps  unnecessarily. 

Finally,  the  pure  model-based  approach  uses  only  the  principle  of 
locality  in  generating  a  path  to  search  for  the  system  fault.  No 
consideration  is  given  to  the  component's  likelihood  of  failure,  or  to 
the  difficulty  of  testing  the  component.  A  slip  ring  may  be  tested  before 
a  gyro  even  though,  based  on  their  mean  time  between  failures  (MTBF),  the 
gyro  is  more  than  seven  times  as  likely  to  be  at  fault,  but  can  be  tested 
in  a  twelfth  of  the  time  (21). 

Conclusions 

A  deep  reasoning  system  is  capable  of  diagnosing  the  fault  in  a 
unit  by  employing  the  principle  of  locality. 

Deep  reasoning  does  not  take  advantage  of  the  lessons  learned  by 
technicians  who  may  have  repaired  the  system  for  some  years. 

Deep  reasoning  does  not  consider  information  that,  while  unrelated  to 
the  structure  of  the  UUT,  is  valuable  in  isolating  the  fault. 

When  ordering  the  tests,  pure  model-based  search  does  not  take  into 
consideration  the  likelihood  of  a  component's  being  at  fault,  nor  does  it 
consider  how  difficult  testing  a  component  may  be. 
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VI.  BPS:  The  Blended  Diagnostic  Systen 

This  Chapter  documents  the  final  phases  of  development  of  BDS.  In 
the  third  phase,  the  systems  from  Chapter  IV  and  V  were  blended  into  a 
single  system.  Phase  4  enhanced  this  system  by  adding  heuristics  to  guide 
the  technician  in  an  intelligent  search  for  the  fault. 

Motive  For  Blending 

Chapter  IV  documented  the  development  of  an  expert  system  for  the 
DHINS  ATE  following  the  traditional  method  described  by  Waterman  (24). 

This  method  resulted  in  a  system  based  on  shallow  reasoning  that  contained 
142  rules.  While  this  system  successfully  handles  all  error  messages 
generated  by  the  ATE,  it  can  only  diagn^ose  situations  for  which  it  has 
been  explicitly  programmed. 

Chapter  V  documented  the  development  of  an  expert  system  for  the  same 
ATE  using  pure  deep  reasoning  techniques.  This  method  resulted  in  the 
development  of  an  expert  system  that  constructs  a  model  of  the  Inertial 
Measurement  Unit  to  reason  about  possible  faults.  Although  the  deep 
reasoning  system  is  capable  of  reasoning  in  situations  for  which  it  was 
not  explicitly  programmed,  it  is  limited  in  that:  (1)  it  does  not  take 
advantage  of  the  lessons  learned  by  experienced  technicians;  (2)  it 
neglects  information  that,  while  not  related  to  structure,  is  nonetheless 
useful  for  isolating  the  fault  of  the  system;  and  (3)  when  ordering  the 
tests,  it  does  not  consider  the  likelihood  of  a  component's  being  at 
fault,  nor  does  it  consider  how  difficult  testing  a  component  may  be. 
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Recently,  attempts  have  been  made  to  design  systems  incorporating 


both  deep  and  shallow  reasoning.  Examples  of  such  systems  are  FIS 
(17:68-76),  IN-ATE  (4:298-351),  and  IDM  (10:188-197).  FIS  assists  a 
knowledge  engineer  in  creating  a  computer  model  of  the  UUT  from 
schematics;  FIS  then  allows  the  addition  of  component  fault-probabilities 
to  assist  in  the  search  for  a  fault.  IN-ATE  assists  the  engineer  in 
building  a  model  from  block  diagrams,  then  recommends  the  best  test  to 
conduct  next  based  on  test-cost  or  fault-probability.  IDH  uses  two 
knowledge  bases,  one  containing  shallow  knowledge,  the  second  containing 
deep  knowledge.  An  executor  module  determines  which  of  the  knowledge  bases 
will  work  on  the  problem. 

Another  approach  to  the  combination  of  deep  and  shallow  reasoning  in 
diagnosis  is  to  emulate  the  human  technician.  The  Blended  Diagnostic 
System  (BDS),  was  developed  with  this  approach  in  mind. 

The  Blended  Diagnostic  System 

The  Blended  Diagnostic  System  (BDS)  uses  both  shallow  and  deep 
reasoning  to  emulate  the  way  a  human  technician  goes  about  diagnosing  a 
fault.  When  confronted  with  a  fault  a  technician  will  normally  (1)  attempt 
a  quick  fix  based  on  his  experience  with  such  a  failure  in  the  past.  If 
the  quick  fix  does  not  solve  the  problem  he  will  (2)  consult  the  manual  to 
determine  which  components  could  cause  such  a  problem  and  then  (3)  test 
the  suspect  components  in  an  order  that  is  based  on  which  one  is  most 
likely  to  be  at  fault. 

BDS  diagnoses  a  fault  in  a  corresponding  manner.  First,  BDS  (1)  uses 
shallow  techniques  derived  from  the  technician's  experience  to  imitate  the 


technician's  initial  "quick  fix"  to  repair  the  fault.  If  such  repair  is 
not  successful,  BDS  (2)  resorts  to  deep  reasoning,  constructing  a  model  of 
the  UUT,  similar  to  the  way  a  technician  resorts  to  consulting  a  manual. 
Finally,  BDS  (3)  uses  heuristics  based  on  the  likelihood  of  a  component's 
being  the  cause  of  a  failure  (based  on  MTBF)  and  the  cost  to  test  the 
component  (based  on  time  required  to  test  the  component)  to  guide  the 
technician  from  place  to  place  in  the  model.  This  blending  of  shallow  and 
heuristically-guided  deep  reasoning  extends  the  class  of  diagnosable 
faults  beyond  those  obtainable  from  either  form  of  reasoning  alone,  and 
reduces  the  number  and  duration  of  tests  to  be  performed.  Appendix  F  lists 
the  code  for  BOS. 

Implementation 

As  was  shown  in  Chapter  IV,  the  first  phase  developed  a  shallow 
reasoning  system  by  encoding  empirical  knowledge  gathered  from  the 
technicians  during  knowledge  engineering  sessions.  During  these  sessions 
the  technician's  method  of  diagnosis,  working  from  each  error  message  to  a 
shop  replaceable  unit  (SRU),  was  captured  in  the  form  of  decision  trees. 
Four  of  these  error  messages  are  common  to  both  the  deep  and  shallow 
systems  developed  in  this  thesis:  velocity  unreasonable,  vt  greater  than  2 
knots,  XY  speed  control,  and  YZ  speed  control. 

The  decision  tree  for  velocity  unreasonable,  first  shown  in  Figure  3 
of  Chapter  IV,  is  presented  again  in  Figure  23  for  the  convenience  of  the 
reader.  This  tree  also  applies  to  the  error  message  vt  greater  than  2 
knots.  A  close  examination  reveals  that  the  knowledge  contained  within  the 
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On  which  test  did  the 
error  message  occur? 


Is  the  direction  of  the 
velocity  N-S,  E-W,  or  other? 


Navigate 


Is  the  direction  of  the 
velocity  N-S,  E-W,  or  other? 


NS  or  EV 


Other 


Wait  for  Platform  to  slew 
Do  directions  change? 


Change  VH 
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Change  VH  EV 


Check  gyro 
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Other 
Platform  Level? 
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Check  Speed  Control  Signals 


-L-j  Bad  |--L.  ------  ■■  -  -  ■  -  Bad 

Interchange  speed  control  - 

cards.  Problem  follows  cards?  Change 

— •  - - pJ  VM 

Bad  Yes  No - 


Check  pick-off 
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Replace 

card 


Replace  gyro 


Figure  23.  Tree  for  Velocity  Unreasonable  and  Vt  Greater  Than  2  Knots. 


decision  tree  can  be  separated  into  (a)  knowledge  derived  from  experience 
that  results  in  "quick  fix"  tactics  and  (b)  knowledge  based  on  structural 
relations  that  require  testing. 

As  an  example  of  knowledge  arising  from  experience,  consider  the 
prompt  relating  to  the  current  test.  This  prompt  does  not  pertain  to 
structure,  however,  the  technician  knows  from  experience  that  this 
information  is  useful  in  isolating  the  fault.  As  an  example  of  quick  fix 
tactics  note  that  no  test  is  required  to  determine  the  direction  of  the 
velocity;  the  direction  can  be  determined  by  reading  an  indicator. 
Likewise,  determining  if  the  platform  is  level, 
or  waiting  for  the  platform  to  slew  requires  no  testing. 

This  portion  of  the  knowledge  was  classified  as  experiential,  or 
shallow  knowledge.  Note  that  the  remainder  of  the  decision  tree  in  Figure 
23  deals  with  structural  knowledge.  Figure  24  shows  the  line  dividing  the 
experiential  from  the  structural  knowledge  in  the  decision  tree. 

The  decision  tree  for  the  error  messages  XY  speed  control,  and  YZ 
speed  control  is  shown  in  Figure  25.  This  tree  is  similar  to  the  tree  in 
Figure  23  in  that  the  knowledge  contained  can  be  separated  into 
experiential  and  structural  knowledge.  From  experience,  the  technician 
knows  that  the  YZ  error  message  is  not  indicative  of  a  fault  unless  it 
occurs  more  than  twice.  This  information  was  not  available  to  the  deep 
reasoning  system;  in  fact,  the  deep  reasoning  system  will  attempt  to 
isolate  a  fault  regardless  of  the  number  of  previous  occurrences.  The 
remainder  of  the  tree  has  information  concerning  structural  knowledge. 
Figure  26  shows  this  tree  divided  into  experiential  and  structural 
knowledge . 


Figure  26.  Speed  Control  Tree  Separated  into  Experiential  and  Structural 
Knowledge. 


Appendix  D  is  a  listing  of  the  code  implementing  the  decision  trees 
in  Figures  22  and  24.  This  code  can  be  divided  into  three  segments;  rules 
that  contain  experiential  knowledge  (rules  23,  30-34,  37,  38),  rules  that 
contain  structural  knowledge  (rules  26-29,  39,  40,  42-60),  and  rules  that 
provide  a  link  from  the  experiential  to  the  structural  segment  (rules  24, 
25,  35,  36,  41). 

The  blending  of  the  two  systems  was  accomplished  by  manipulating 
these  rules.  The  rules  containing  the  experiential  knowledge  were 
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preserved;  the  rules  concerning  structural  knowledge  were  eliminated 
(rules  43-60  were  preserved  only  because  they  are  used  by  other  error 
messages);  and  the  rules  providing  the  link  were  modified  by  replacing 
their  conclusion  block  with: 

::C0NCLUSI0N  action! I]  =  "Begin  Deep  Diagnosis." 

Figure  27  shows  the  modified  version  of  rule  39.  Rule  39  was  first  seen  in 
Chapter  IV,  Figure  7. 


DEFINE  RULE 

Rule039 

: : APPLIED. TO 

I:  IMU 

:: PREMISE 

check. for. level. platform[I]  and 

azimuth. equal. zero! I] 

: : CONCLUSION 

action(I]  >  "Begin  Deep  Diagnosis." 

Figure  27.  Rule  39  Modified  To  Initiate  Deep  Reasoning. 


Next,  the  top  level  control  block  of  the  shallow  reasoning  system  was 
modified  by  adding  the  declaration  of  a  name  and  subcomponents  to  the 
instance  of  IMU  created  (both  systems  share  this  class  instance)  and 
adding  the  following  conditional  statement: 

if  action(I]  >"Begin  Deep  Diagnosis 
then  invoke  deep. diagnosis 

The  resulting  control  block  can  be  seen  in  Figure  28.  Finally,  the  top 
level  control  block  of  the  deep  reasoning  system  was  removed,  and  the 
remaining  code  for  the  deep  reasoning  system  was  appended  to  the  shallow 
reasoning  system. 
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DEFINE  CONTROL. BLOCK  ABOUT. IMU 

: ; INVOCATION  top . level 

:: TRANSLATION  "diagnose  faults  in  the  IMU 

::BODY 
begin 

vars  I:imu; 

display  spaces(25)  !  "THE  DMINS  FAULT  ADVISOR"! 
new. line( ) ; 

create. instance  imu  called  I  with 
begin 

name.of[Il  =  "IMU"; 
has . subcomponen  til]; 
critical. test[I] ; 
output. test. ok[ I i<-1.0>; 
end; 

determine  error.niessage(I] ; 
determine  action[I]; 
if  action[Il  =  "Begin  deep  diagnosis" 
then  invoke  DIAGNOSE. IMU. FAULT( I) 
else  begin 

invoke  display . recommendations(I) ; 
determine  fault(I]; 
end; 

end 

END. DEFINE 


Figure  28.  Modified  Top  Level  Control  Block. 


The  resulting  system  allows  both  structural  and  experiential 
knowledge  to  be  used  in  diagnosing  a  problem.  It  can  take  advantage  of  the 
technician's  experience  and  employ  knowledge  unrelated  to  structure.  The 


search  generated  by  the  principle  of  locality,  however,  does  not  consider 
the  likelihood  of  a  component's  being  faulty,  nor  does  it  consider  the 


difficulty  of  testing  the  component. 


Adding  Heuristics  to  the  Model 

The  search  generated  by  the  system  developed  in  Phase  3  considers 
only  the  principle  of  locality.  This  would  be  acceptable  if  all  components 
were  equally  fallible,  and  equally  accessible.  However,  this  is  not  the 
case.  Based  on  mean  time  between  failures  (MTBF),  a  gyro  is  more  than 
seven  times  as  likely  to  fail  as  a  slip  ring.  In  addition,  a  slip  ring 
requires  12  times  as  long  to  test  as  a  gyro  (21).  It  is  desirable  to  use 
the  principle  uf  locality  to  identify  components  that,  by  their  manner  of 
connection,  could  reasonably  be  the  cause  of  the  fault,  but  to  test  the 
suspected  components  in  an  order  that  will  ensure  that  the  most-promising, 
least-costly  tests  are  performed  first  and  that  the  least-promising, 
most-costly  tests  are  performed  only  as  a  last  resort.  This  was  the  goal 
of  the  fourth  and  final  phase. 

Two  attributes  were  created  to  be  associated  with  each  component  in 
the  DHINS  IMU  model.  They  are  RISK,  which  is  a  measure  of  the  likelihood 
of  the  component's  being  at  fault  based  on  MTBF,  and  TEST-COST,  which  is  a 
measure  of  the  difficulty  to  test  the  component  based  on  the  time  to  test 
(in  person-minutes).  Engineers  at  Newark  were  interviewed  to  determine 
RISK  and  TEST-COST  values  for  each  of  the  components  in  the  model  of  the 
DHINS  IMU  (21).  The  results  are  shown  in  Table  1. 

To  determine  the  feasibility  of  ordering  the  test,  each  component  in 
the  BDS  code  was  assigned  its  corresponding  value  for  the  attribute  RISK. 
Next,  the  DEEP. DIAGNOSE  control  block  from  Figure  17  was  modified  to 
prioritize  the  search  by  values  of  RISK,  from  highest  risk  to  lowest  risk. 
Code  and  comments  for  the  control  block  are  in  Appendix  E.  The  pseudo  code 
for  this  algorithm  appears  in  Figure  29. 
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Table  1.  Values  for  RISK  and  TEST-COST. 


Model 

Component 

Risk 

Test-Cost 

Top  Level 

Velocity  Meter  Function 

Ned 

Med 

Gyro  Speed  Control 

High 

Med 

Gyro  Torquing  Function 

High 

Ned 

Platform  Torquing  Function 

Low 

Med 

Sequence  Timing  Function 

Low 

Low 

Velocity  Meter  Function 

Test  Equipment 

Low 

Low 

X  Velocity  Meter 

High 

Ned 

Y  Velocity  Meter 

High 

Ned 

Frequency  Standard  Function 

Low 

Low 

Power  Distribution 

Low 

Low 

Gyro  Speed  Control 

DC  AMP 

Med 

Low 

Bandpass  Filter 

Med 

Low 

Gyro  Buffer  ECA 

Med 

High 

Gyro 

High 

Med 

Slip  Ring 

Low 

High 

Power  Supply 

Low 

Low 

Gyro  Torquing  Function 

Gyro  Torquer 

High 

Ned 

Torque  Driver 

Ned 

Low 

Precision  Current  Network 

Med 

High 

Case  search  level  of  the  current  path  is: 

High; begin 

if  Component  is  not  high  risk  and  does  not  have  multiple  inputs 
then  if  Component  is  an  end. point 

then  invoke  deep. diagnose(Start, Start, Component, Hed) 
else  designate  the  input  of  the  Component  as  Componentl  and 
invoke  deep. diagnose(Componen tl,S tar t , Finish, High) 
else  test  the  output  of  Component 
if  output. test. ok(Componentl 

then  invoke  deep. diagnose(Start, Start, Component, Med) 


Figure  29.  Pseudo  Code  For  the  Modified  DEEP. DIAGNOSE  Control  Block. 
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else  begin 

determine  if  Component  has  a  bad  input; 
if  Component  has  a  bad  input  called  component  1 
then  invoke  deep. diagnose(componentl,componentl, finish, high) 
else  if  Component  has  subcomponents 
then  begin 

build  the  subcomponents  and  designate  the  one 
with  the  same  output  as  Component  as  Component2; 
invoke  deep . diagnose (Component 2 , Component 2 , D , high ) ; 
end 

else  the  Component  is  the  fault 

end ; 

end; 

Medium:begin 

if  the  Risk  of  Component  is  low 
then  begin 

if  Finish  =  Component 

then  invoke  deep. diagnose(Start, Start, Finish, Low) 
else  invoke  deep. diagnose(Componentl, Start, Finish, Med) 
end 

else  if  the  output  of  Component  is  OK 

then  invoke  deep. diagnose(Start, Start, Component, Low) 
else  if  Component  has  a  bad  input  called  Componentl 

then  invoke  deep. diagnose(Componentl, Componentl, D,Hed) 
else  if  Component  has  subcomponents 
then  begin 

build  the  subcomponents  and  designate  the  one  with 
the  same  output  as  Component  as  Component2; 
invoke  deep. diagnose( Componen t2 , Component 2, D, High) ; 
end 

else  the  Component  is  the  fault 

end; 

Low: begin 

if  Component  has  a  bad  input  called  Componentl 
then  invoke  deep. diagnose(Componentl, Componentl, Finish, Low) 
else  if  Component  has  subcomponents 
then  begin 

build  the  subcomponents  and  designate  the  one  with  the  same 

output  as  Component  as  Component2; 

invoke  deep . diagnose ( Componen 1 2 , Componen 1 2 , D , H igh ) 

end 

else  the  Component  is  the  fault 
end 


Figure  29.  Pseudo  Code  For  the  Modified  DEEP. DIAGNOSE  Control  Block  (Cont'd) 
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The  algorithm  has  been  enhanced  to  ensure  that  the  highest  risk 
components  (that  is,  the  components  most  likely  to  be  at  fault)  are  tested 
first  followed  by  components  with  medium  risk,  then  those  with  low  risk. 
Each  time  the  control  block  is  invoked,  four  arguments  are  passed; 
COMPONEfT'  '  '\RT,  FINISH,  and  PATH.  START  is  the  first  component  in  the 
current  patn;  the  output  of  START  is  known  to  be  bad,  FINISH  is  the  last 
component  in  the  current  path;  the  inputs  of  FINISH  are  known  to  be  good 
(initially,  FINISH  is  set  to  a  dummy  component  since  its  value  has  not 
been  determined).  PATH  designates  a  Search  Level;  the  Search  Level  can 
assume  one  of  three  values:  high,  med,  or  low. 

The  program  begins  with  START  and  COMPONENT  set  to  IMU,  FINISH  is  set 
to  the  dummy  component,  and  the  Search  Level  is  high.  The  model  for  IMU 
will  be  constructed,  and  diagnosis  will  begin.  As  long  as  the  Search  Level 
remains  high,  only  components  considered  critical  (those  with  a  high  RISK 
level,  or  those  with  multiple  inputs)  are  tested.  The  output  of  COMPONENT 
will  be  tested  first;  if  it  is  good,  FINISH  will  be  set  to  this  component, 
and  DEEP. DIAGNOSE  will  be  invoked  with  the  same  value  for  START,  COMPONENT 
set  to  START,  and  the  Search  Level  set  to  med.  If  the  output  of  COMPONENT 
is  bad,  the  inputs  to  COMPONENT  will  be  tested.  If  an  input  is  bad,  the 
component  responsible  for  the  bad  input  will  become  the  new  value  for 
START  and  COMPONENT,  FINISH  will  remain  a  dummy  component  and  the  Search 
Level  will  remain  high.  If,  after  all  critical  components  are  tested,  the 
end  of  the  path  is  reached  without  identifying  the  fault,  a  medium  level 
search  begins  with  START  and  COMPONENT  set  equal  to  the  current  value  of 
START,  and  the  endpoint  as  the  value  of  FINISH.  If  a  component  is  found 
with  a  bad  output  and  all  good  inputs,  it  will  be  tested  for 
subcomponents.  If  it  has  subcomponents,  they  will  be  built  and  diagnosis 


will  resume  with  a  high  level  search,  START  and  COHPONENT  will  assume  the 
value  of  the  subcomponent  with  the  same  output  as  the  parent  component, 
and  FINISH  will  be  set  as  a  dummy  component.  If  no  subcomponents  exist, 
COMPONENT  is  reported  as  the  fault. 

During  the  Medium  level  search,  only  medium  risk,  components  are 
tested.  If  the  output  of  COMPONENT  is  good,  a  low  level  search  will  begin 
with  the  current  value  of  START  for  START  and  COMPONENT,  and  COMPONENT  as 
the  new  value  for  FINISH.  If  the  output  is  bad,  the  input  will  be  tested. 
If  the  input  is  bad,  a  medium  level  search  will  continue  with  the 
component  responsible  for  the  bad  input  as  the  new  value  for  START  and 
COMPONENT;  FINISH  will  remain  set  to  the  same  value.  If,  after  all  medium 
RISK  components  are  tested,  the  end  of  the  path  is  reached  without 
identifying  the  fault,  a  low  level  search  begins  with  START  and  COMPONENT 
set  equal  to  the  current  value  of  START,  and  the  endpoint  as  the  value  of 
FINISH.  If  during  the  medium  level  search  a  component  is  found  to  have  a 
bad  output  and  a  good  input,  it  will  be  handled  exactly  as  it  is  during 
the  high  level  search. 

During  the  low  level  search,  all  components  will  be  tested  since  only 
low  risk  components  remain  in  the  path.  If  during  the  low  level  search  a 
component  is  found  to  have  a  bad  output  and  a  good  input,  it  will  be 
handled  exactly  as  it  is  during  the  high  level  search. 

A  component  with  multiple  inputs  i;;  considered  a  critical  test  point, 
and  for  that  reason  is  tested  during  the  high  level  search  regardless  of 
its  associated  RISK  value.  This  prevents  the  search  from  considering 
branches  unnecessarily.  If  the  output  of  the  component  is  good,  the  inputs 
are  not  considered  at  all.  If  the  output  of  the  component  is  bad,  the 
inputs  will  be  tested  in  order  of  their  respective  RISK  value,  from 
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DEFINE  RULE  RULE. 201 
; : APPLIED. TO  COMPONENT: i mu. component 

::PRENISE  already. exi s t ing(C0NP0NENTl : imu. component  | 

de  t  ermined  ? ( connec  ted . to I COMPONENTl , COMPONENT  J ) 
and  connected. to  (COMPONENTl, COMPONENT]  known 
and  risk (COMPONENTl I  is  high 
and  output. test. ok(C0HP0NENTl]  thought. not) 

::C0NCLUSI0N  bad. input (COMPONENT]  =  connected. to(C0MP0NENTl , COMPONENT] ; 
END. DEFINE 

DEFINE  RULE  RULE. 202 
: :APPLIED.TO  COMPONENT: imu. component 

::PREMISE  already. existing(COMPONENTl:imu. component  | 

de  term! ned  ? ( connected . to ( COMPONENTl , COMPONENT ] ) 
and  connected. to  ( COMPONENTl , COMPONENT ]  known 
and  risk(CONPONENTl]  is  med 
and  output. test. ok(C0MP0NENTl]  thought. not) 

::C0NCLUSI0N  bad. input (COMPONENT]  -  connected. to ( COMPONENTl .COMPONENT] ; 
END. DEFINE 

DEFINE  RULE  RULE. 203 
: :APPLIED.TO  COMPONENT: imu. component 

::PREMISE  already. existing(CONPONENTl:imu. component  | 

determined? (connec ted. to(C0MP0NENTl .COMPONENT] ) 
and  connected. to  (COMPONENTl, COMPONENT]  known 
and  risk] COMPONENTl ]  is  low 
and  output . test .ok(COMPONBNTl ]  thought. not) 

:!C0NCLUSI0N  bad . input (COMPONENT]  =  connected. to(CONPONENTl, COMPONENT] ; 
END. DEFINE 


Figure  30.  Rules  to  Order  Search  of  Component's  Inputs. 


The  DEEP. DIAGNOSE  control  block  can  be  further  modified  to  include 
consideration  of  the  attribute  TEST-COST  by  increasing  the  number  of  legal 
values  for  the  level  of  search  and  adding  the  necessary  code  for  the  case 
statement  in  the  DEEP. DIAGNOSE  control  block.  Due  to  the  emphasis  on 


maintainability  in  this  effort,  it  was  determined  that  the  increase  in 
complexity  of  the  program  associated  with  adding  TEST-COST  outweighed  the 
benefits  of  this  additional  prioritizing. 


Summary 

BDS  begins  fault  diagnosis  by  applying  shallow  reasoning  in  an 
attempt  to  isolate  the  fault.  If  this  attempt  fails,  BDS  constructs  a 
model  of  the  UUT  based  on  structural  knowledge.  BDS  determines  which 
components  are  possible  candidates  based  on  the  principle  of  locality, 
then  orders  these  components  based  on  the  likelihood  that  a  component 
might  fail  and  the  time  required  to  test  the  component.  Finally,  BDS  uses 
this  information  to  suggest  a  sequence  of  tests  to  the  technician,  guiding 
him  adaptively  to  the  location  of  the  fault. 

This  blend  of  reasoning-approaches  is  a  better  emulation  of  a 
technician's  behavior  than  is  either  of  the  approaches  alone.  When  a  fault 
occurs  a  technician  tries  the  repairs  he  thinks  are  "obvious."  He  does  not 
get  these  from  a  book  or  (for  the  most  part)  from  knowledge  of  the  system, 
but  from  his  experience  that  the  last  several  times  a  situation  like  this 
occurred  the  problem  was  with  component  X.  Only  if  the  "quick  fix"  to 
component  X  does  not  solve  the  problem  does  the  technician  resort  to  the 
manual  to  trace  the  fault  back  to  the  component  responsible. 


VII.  Conclusions  and  Recoanendations 


Su— ary 

The  objective  of  this  thesis  was  to  investigate  the  use  of  deep 
reasoning  and  shallow  reasoning  in  diagnostic  expert  systems.  This 
investigation  included  blending  the  two  type  of  reasoning  in  a  manner 
which  capitalizes  on  the  strengths  of  each  while  diminishing  their 
weaknesses . 

The  thesis  focused  on  the  development  of  the  Blended  Diagnostic 
System  (BDS),  an  expert  system  which  blends  the  two  forms  of  reasoning  by 
emulating  a  technician's  method  of  diagnosing  faults.  BDS  begins  fault 
diagnosis  by  applying  shallow  reasoning  in  an  attempt  to  isolate  the 
fault.  If  this  attempt  is  not  successful,  BDS  constructs  a  model  of  the 
unit  under  test  and  diagnoses  faults  from  this  model  in  an  order  based  on 
the  likelihood  of  the  component's  being  the  fault  and  the  difficulty  of 
testing  the  component. 

The  system  selected  to  test  the  performance  of  BDS  is  the  Dual 
Miniature  Inertial  Navigation  System  (OMINS).  Repair  of  DHINS  is  the 
responsibility  of  the  Aerospace  Guidance  and  Metrology  Center  (AGMC) 
located  at  Newark  APB,  OH.  A  prototype  of  BDS  was  developed  for  DHINS  in 
a  four  phase  approach.  First,  an  expert  system  employing  only  shallow 
reasoning  was  developed  using  traditional  knowledge  engineering 
techniques.  Second,  an  expert  system  was  developed  that  employs  deep 
reasoning  to  construct  a  model  of  the  unit  under  test  (UUT).  Third,  the 
shallow  and  deep  reasoning  systems  were  blended.  Finally,  the  deep 
reasoning  portion  of  the  system  was  enhanced  by  employing  heuristically 


guided  search-techniques  to  guide  the  technician  from  place  to  place  in 
the  model. 

Knowledge  acquisition  sessions  performed  for  the  shallow  and  deep 
reasoning  portions  of  BDS  differed  in  that  the  source  of  the  knowledge  for 
the  shallow  reasoning  system  was  an  expert,  whereas  the  source  of  the 
knowledge  for  the  deep  reasoning  system  was  a  manual,  with  an  expert 
acting  only  as  an  interpreter.  Difficulties  during  the  two  sessions  were 
similar.  In  both  cases,  there  was  a  tendency  for  the  experts  to  go  into 
more  detail  than  was  necessary  to  build  the  system.  Since  time  was 
limited,  it  was  necessary  to  ensure  that  discussions  remained  relevant. 

The  existence  of  the  technical  manual  in  the  case  of  the  deep  reasoning 
system  was  a  valuable  asset  in  that  it  served  as  a  point  of  focus  for  the 
interview.  No  such  focal  point  existed  for  the  shallow  reasoning  system, 
except  for  the  error  message  written  at  the  top  of  the  page  of  each 
decision  tree. 

Assessment 

An  assessment  of  the  prototype  developed  for  this  thesis  reveals 
several  key  features  as  well  as  a  few  limitations.  Key  features  of  the  BDS 
prototype  include: 

1.  BDS  runs  on  an  ^  class  machine.  By  developing  the  system  on  an  AT 

class  personal  computer  as  opposed  to  a  specialized  vorksta«’^on  such  as 
a  Lisp  machine  (required  by  lOM)  or  a  Sun  workstation  (required  by 
FIS),  there  was  an  immediate  savings  of  $25,000  to  AGHC.  More 
importantly,  BOS  provides  a  model  for  similar  expert  systems  to  be 
extended  to  ATE  at  Newark  AFB  and  other  maintenance  organizations. 
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which,  because  their  primary  mission  is  not  research,  can  not  justify 
the  expenditure  for  specialized  work  stations. 

2.  BPS  is  efficient .  The  completed  code  responds  to  any  operator  input 
within  ten  seconds.  The  requirement,  as  stated  in  Chapter  II  was  ten 
minutes. 

3.  BPS  is  adaptable.  As  the  PHINS  system  (or  any  system  to  which  a  BPS- 
like  expert  system  could  be  applied)  ages,  different  parts  become  more 
prone  to  failure.  The  attribute  Risk  allows  BPS  to  take  this  fact  into 
consideration,  and  adjust  the  search  accordingly. 

4.  BPS  is  equipped  with  an  explanation  facility.  If  the  user  requests  an 
explanation  during  the  shallow  reasoning  session,  BPS  provides  an 
explanation  as  to  why  such  a  test  is  desirable  through  the  S.l 
explanation  facility. 

5.  BPS  allows  for  the  addition  of  a  historical  database.  By  building  the 
attribute  Fault  into  the  program,  a  "hook"  has  been  made  available  that 
will  allow  the  program  to  store  and  retrieve  information  about  previous 
faults.  This  will  allow  the  system  to  detect  recurrent  problems  and  act 
accordingly. 

6.  BPS  allows  for  integration  wi th  the  ATE.  Using  S.l's  feature  of 
external  functions,  attributes  that  are  already  in  the  program  can  be 
retrieved  directly  from  the  LAN  by  changing  the  LEGAL. MEANS  slot  of  the 
attribute  to  the  name  of  the  external  function. 

7.  BPS  has  a  complete  framework.  The  program  already  handles  all  possible 
error  messages  through  shallow  reasoning.  The  main  cr.itrol  block  that 
drives  the  deep  reasoning  system  is  already  developed.  Three  out  of  ten 
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functions  are  complete  for  the  OHINS  model.  Using  these  three  models  as 
a  guide,  it  will  be  a  relatively  simple  matter  to  extend  the  model  for 
the  remaining  seven  functions. 

As  mentioned,  the  BDS  prototype  has  limitations.  These  limitations 
include: 

1.  BDS  assumes  only  a  single  fault  exists.  The  most  restrictive  limitation 
of  BDS  is  that  the  algorithm  employed  in  the  deep  reasoning  portion  of 
the  system  assumes  that  only  a  single  fault  exists. 

2.  Performance  of  the  explanation  facility  deteriorates  during  deep 
reasoning.  Due  to  the  recursive  nature  of  the  deep  reasoning  algorithm, 
requests  for  explanations  during  deep  reasoning  are  of  limited  value. 

Conclusions 

During  research  for  this  thesis,  it  was  noted  that  while  shallow 
reasoning  is  a  useful  method  of  incorporating  an  expert's  experience  with 
a  unit  under  test  (UUT),  it  is  unable  to  accommodate  situations  that  have 
not  been  previously  encountered  in  existing  systems.  Furthermore,  deep 
reasoning  is  a  useful  method  for  incorporating  structural  knowledge  into 
an  expert  system,  however,  it  neglects  the  technician's  experience  and 
does  not  make  use  of  information  that,  while  not  related  to  structure,  is 
useful  for  diagnostics  (e.g.  previous  faults,  current  test). 

It  was  also  noted  that  a  model-based  search  based  strictly  on  the 
priri'-iple  of  locality  does  not  take  into  consideration  the  fact  that  all 
components  are  not  equally  likely  to  be  the  cause  of  the  fault,  nor  does 
it  consider  that  component  testing  has  varying  levels  of  difficulty. 


It  was  further  observed  that  technicians  use  a  combination  of  shallow 
reasoning,  deep  reasoning,  and  heuristically  guided  search  techniques  to 
isolate  a  fault.  First  they  attempt  quick  fixes  (shallow  reasoning),  and, 
if  these  are  not  successful  they  resort  to  the  technical  manual  (deep 
reasoning)  to  identify  components  that  could  possibly  cause  the  fault. 
Finally,  they  use  heuristics  based  on  the  likelihood  that  a  component  will 
fail  and  the  difficulty  involved  in  testing  the  component  to  determine  the 
order  in  which  the  components  should  be  tested. 

Based  on  these  observations,  and  the  prototype  of  the  Blended 
Diagnostic  System,  the  following  conclusions  can  be  made: 

1.  It  is  possible  to  blend  deep  and  shallow  reasoning  by  initially 
applying  the  technician's  experience,  and  if  not  successful,  resorting 
to  structural  diagnosis  to  isolate  a  fault. 

2.  The  performance  of  the  deep  reasoning  portion  of  such  a  blended  system 
can  improved  by  employing  heuristically-guided  search  techniques  rather 
than  relying  solely  on  the  principle  of  locality. 

3.  The  resulting  blend  of  reasoning  techniques  is  a  better  emulation  of  a 
technician's  method  of  diagnosing  a  fault  than  is  either  shallow  or 
deep  reasoning  applied  alone. 

4.  This  method  of  blending  shallow  and  heuristically-guided  deep  reasoning 
extends  the  class  of  diagnosable  faults  beyond  the  class  for  either 
form  of  reasoning  alone,  and  reduces  the  number  and  duration  of  tests 
to  be  performed  by  the  technician. 

5.  Use  of  a  document  as  a  knowledge  source  does  not  necessarily  eliminate 
the  need  for  an  expert  during  knowledge  acquisition.  Consequently,  many 
of  the  problems  associated  with  interviewing  remain.  The  document  does, 
however,  provide  a  point  of  focus  for  discussion,  thereby  providing  a 
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convenient  point  to  which  the  knowledge  engineer  can  return  when 
discussions  degrade  to  an  unproductive  state. 

Reco—enda  t  i  ons 

Specific  areas  for  further  research  into  the  area  of  blending  deep 

and  shallow  reasoning  include  generic  improvements  to  BDS  (recommendations 

1-3)  as  well  as  improvements  to  BOS  as  it  applies  to  DHINS 

(recommendations  4-8). 

1.  Develop  a  simple  graphic  display  to  interface  with  BDS.  This  display, 
similar  to  that  of  FIS,  would  be  a  block  diagram  of  the  components  of 
the  system.  Each  block  would  be  color-coded  to  indicate  its  current 
status  (e.g.,  red  -  faulty,  yellow  -  suspect,  green  -  good,  orange  - 
not  as  yet  tested). 

2.  Separate  the  knowledge  bases  from  the  control  mechanisms  to  develop  a 
shell  that  will  allow  the  knowledge  engineer  to  use  BDS  as  an  aid  to 
developing  an  expert  system  to  work  with  any  ATE.  This  shell  could  then 
be  tested  on  an  existing  Air  Force  System. 

3.  Extend  the  reasoning  algorithm  in  the  deep  reasoning  portion  to  allow 
for  the  possibility  of  multiple  faults. 

4.  Complete  the  model  for  the  deep  reasoning  portion  of  the  code  to 
include  all  ten  of  the  functions  of  the  IMU. 

5.  Interface  the  program  to  directly  receive  the  parameters  available  on 
the  local  area  network  at  AGMC.  This  should  start  with  an  attempt  to 
retrieve  the  error  message  directly,  and  then  be  expanded  to  include 
all  possible  parameters. 
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6.  Extend  the  rules  and  models  in  BDS  so  that  it  is  capable  of  diagnosing 
faults  during  Mode  B  tests. 

7.  After  the  system  grovs  to  a  size  such  that  it  has  twice  the  number  of 
its  current  rules,  implement  the  rule-categories  discussed  in  Chapter 
IV  and  determine  if  efficiency  is  increased. 

8.  Interface  the  system  to  the  DMINS  historical  database,  when  such  a 
database  is  developed  by  the  engineers  at  Newark  AFB. 


Appendix  A:  Mode  A  Testing 

The  expert  system  operation  is  limited  to  Mode  A  tests.  This  appendix 

describes  the  sequence  of  testing  during  a  typical  Mode  A  test. 

1.  Shim  Cal  -  Tests  velocity  meters.  First  pass  compares  current  numbers 
of  bias  and  scale  factor  with  numbers  obtained  during  last  test.  If 
numbers  are  within  a  predefined  error  margin  the  next  test  begins. 
Otherwise  this  test  is  repeated.  If  it  passes,  continue  next  test. 
Otherwise  halt  and  report  failure.  Up  to  four  hours  required. 

2.  Gyro  Cal  -  Tests  Gyros.  Up  to  three  passes  can  be  run.  If  any  are 
passed,  test  continues.  Otherwise  failure  is  reported.  Requires  up  to 
eighteen  hours. 

3.  Self  Align  -  Tests  ability  of  IHU  to  perform  a  self  alignment.  Requires 
up  to  four  hours. 

4.  Nav  Align  -  Tests  the  ability  of  the  IMU  to  navigate.  Requires  up  to 
sixteen  hours. 

5.  Navigation  -  Further  test  of  the  IMU's  ability  to  navigate  correctly. 
Requires  thirty  hours  for  complete  navigation  test. 
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Appendix  B:  The  62  Error  Messages 


The  DMINS  ATE  is  capable  of  generating  62  possible  error  messages. 
BDS  uses  these  error  messages  to  initiate  diagnosis.  The  error  messages 
are  listed  below. 


1.  velocity. unreasonable  32. 

2.  vt. greater. than. 2. knots  33. 

3.  xy. speed. control  3A. 

4.  yz. speed. control  35. 

5.  imu. major  36. 

6.  no. input. 3. axes  37. 

7.  no. input. az  38. 

8.  no. input . pi tch  39. 

9.  no. input . roll  40. 

10.  automatic. shutdown  41. 

11.  imu. 0. load  42. 

12.  imu. 0. temp  43. 

13.  pwr. interrupt  44. 

14.  dec. o. load. o. temp  45. 

15.  dec. 0. temp  46. 

16.  i.c. fault  47. 

17.  comp. tie. in. sw. on  48. 

18.  i . c. fault . inhb.enab  49. 

19.  seq.cnt.no. compare  50. 

20.  i . c. data. loop. fault  51. 

21.  i .c. fault. cont  52. 

22.  in.parity. test . inhb.enab  53. 

23.  out .word. par . inhb. enab  54. 

24.  input .parity . fault  55. 

25.  output. word. parity. fault  56. 

26.  output. word. parity. cont  57. 

27.  excess. angle  58. 

28.  servo. disable  59. 

29.  major. reset . fault  60. 

30.  z.stab  61. 

31.  system. in. free. run  62. 


minor . reset . fault 
minor . fault . cont 
imu. minor 
plat. stab. abort 
xvm. precounter . fault 
yvm. precounter. fault 
both. vm. precounter. failure 
vm. bi te. failure 

x. gyro. torque. fault 

y. gyro. torque. fault 

z.  gyro. torque. fault 
system. not .properly. caged 
gyro. hot 

gyro. cold 

gyro. temp. normal 

mux.decoder.dl. fault 

cage. xy.dl. fault 

cage. yz.dl. fault 

gyro.start.dl. fault 

gyro . run . dl . fault 

uyk . good . dl . f aul t 

input.parity.dl. fault.mux04 

inpu t. par ity.no. 2. dl. fault 

output .word .pari ty.dl. fault .mux09 

vt.vr. greater. than. 3. knots 

fflinisins.vel.dif. exceeds. limit 

minisins. pos.dif. exceeds. limi t 

parity. test. 1. no. go 

parity. lest .2. no. go 

parity. test. 3. no. go 

put . intercom. test . no. go 


Appendix  C:  The  38  Shop  Repairable  Units  (SRU) 

R 

This  appendix  lists  the  38  individual  shop  repairable  units  (SRU) 
comprised  by  the  Inertial  Measuring  Unit.  The  goal  of  the  expert  system  is 
to  isolate  an  IMU  fault  to  one  or  more  of  the  SRUs  listed. 
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ID# 

Name 

3A1 

Bandpass  Filter  and  Shift  Register 

3A2 

Bandpass  Filter  and  Shift  Register 

3A3 

Precision  Torquing  Driver  (X) 

3A4 

Precision  Torquing  Driver  (Y) 

3A5 

Precision  Torquing  Driver  (Z) 

3A7 

Platform  Electronic  Switch 

3A8 

Shorting  Plug 

3A9 

Precision  Current  Network 

3A10 

Stable  Platform 

3AIOA3 

Displacement  Gyroscope  (X-Y) 

3A10AA 

Displacement  Gyroscope  (Y-Z) 

3A10A7 

Velocity  Meter  (X) 

3A10A8 

Velocity  Meter  (Y) 

3A10AR1 

Resolver  Buffer  Amp 

3A10AR5 

Gyro  Buffer  Amp  (X-Y) 

3A10AR6 

Gyro  Buffer  Amp  (Y-Z) 

3PS1 

640  Hz  Power  Supply  (X-Y) 

3PS2 

640  Hz  Power  Supply  (Y-Z) 

3PS3 

Power  Cube 

3PS7 

400  Hz  Power  Supply  No. 2 

3PS8 

400  Hz  Power  Supply  No.l 

3PS9 

Triangle  Generator  and  Case  Rotation  Power  Supply 

3PS10 

4.8  KHz  Power  Supply 

3PS11 

Frequency  Standard 

3AR1 

D.C.  Amplifier  (X-Y) 

3AR2 

D.C.  Amplifier  (Y-Z) 

3AR3 

Synchro  Signal  Buffer  Amp 

3AR4 

Gyro  Cage  Amp 

3AR5 

Thermoelectric  Signal  Amp. 

3AR6 

Gyro  Temperature  Controller 

3AR7 

Gimbal  Cage  Amp. 

3AR8 

Platform  Signal  Amp 

3AR9 

Platform  Electronic  Control  Amp  (Roll) 

3AR10 

Platform  Electronic  Control  Amp  (Pitch) 

3AR11 

Platform  Electronic  Control  Amp  (Azimuth) 

3AR12 

Gimbal  Rate  Electronic  Control  Amp 

(Roll) 

3AR13 

Gimball  Rate  Electronic  Control  Amp 

(Pitch) 

3AR14 

Gimbal  Rate  Electronic  Control  Amp 

(Azimuth) 
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Appendix  D:  Rules  for  XT  Speed  Control,  TZ  Speed  Control, 

Velocity  Unreasonable,  an3  Vt  Greater  Than  2  Knots 


Z***********************************************************************/ 


/*  */ 
I*  Rules  023  -  029  determines  the  cause  of  the  following  messages:  */ 

/*  xy. speed. control,  */ 

(*  yz. speed. control.  */ 


DEFINE  RULE  rule023 
:: APPLIED. TO  I:IMU 

::PRENISE  error.message[I]  is  yz. speed. control  and 
not  yz. fault. occur red. more. than. tvicefl] 

:  .-CONCLUSION  begin 

actionfl]  >  "No  action  is  required.  If  the  YZ  speed 
control  error  has  not  occurred  more  than  twice,  it  is 
normally  not  a  problem"; 
fault(I]  >  none; 
end 

END. DEFINE 

DEFINE  RULE  rule024 
:: APPLIED. TO  I:IMU 

:: PREMISE  error.message{I]  is  xy. speed. control 
: :C0NCLUSI0N  check. speed. control. signal(I] 

END. DEFINE 


DEFINE  RULE  rule025 
:: APPLIED. TO  I:IMU 

:: PREMISE  error .message! I]  is  yz. speed. control  and 

yz. fault .occur red. more. than. twice[I] 

: tCONCLUSION  check. speed. control. signal(I] 

END. DEFINE 


DEFINE  RULE  rule026 
s; APPLIED. TO  I:IMU 

:: PREMISE  check. speed. control. signal! I]  and 
speed. control. signal. good!I) 

::C0NCLUSI0N  action!I]  «  "Check  the  discretes  on  the  modules. 

module  problem  is  suspected" 


END. DEFINE 
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DEFINE  RULE  rule027 
:: APPLIED. TO  I:IMU 

:: PREMISE  check. speed. control. signal! I]  and 
not  speed. control. signal. good! I ] 

: :CONCLUSION  exchange. speed. control. cards! I) 
END. DEFINE 
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DEFINE  RULE  rule028 
APPLIED. TO  I:IHU 

:: PREMISE  exchange. speed. control. cards( I]  and 

no t  problem .foil ovs . speed . con t rol . card [ I ] 
:: CONCLUSION  begin 

replace .faulty. component ( I ] ; 
fault(I]  -  corresponding. gyro; 
end 

END. DEFINE 

DEFINE  RULE  rule029 
APPLIED. TO  I:IMU 

::PRENISE  exchange. speed. control. cardsfl]  and 

problem . follows . speed . control . card ( I ] 

:: CONCLUSION  begin 

replace . f aul ty . componen  1 1 1 ] ; 
fault [I I  >  corresponding. speed. card; 
end 

END. DEFINE 


/*  */ 
/*  This  group  of  rules  Includes  rules  030  -  042  and  troubleshoots  the  */ 
/*  following  two  error  messages:  */ 

f*  velocity. unreasonable,  */ 

/*  vt. greater. than. 2. knots.  */ 

/*  In  addition,  this  section  uses  the  routine  Check  Gyro  Circuit,  which  */ 
/*  starts  with  rule  043.  */ 


DEFINE  RULE  rule030 
:: APPLIED. TO  I:IMU 

::PREHISE  error.message[I]  is  in  (velocity. unreasonable, 

vt. greater. than. 2. knots)  and 

test[I]  is  gyro. cal 
: '.CONCLUSION  check. posit ion( I  ] 

END. DEFINE 

DEFINE  RULE  rule031 
:: APPLIED. TO  ItIMU 

::PREMISE  error .message! I ]  is  in  (velocity. unreasonable, 

vt. greater. than. 2. knots)  and 

testfl]  is  navigate 

: :C0NCLUSI0N  check. velocity. direction(I] 

END. DEFINE 
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DEFINE  RULE  rule032 
APPLIED. TO  I:IMU 

::PREMISE  error .message[I ]  is  in  {velocity. unreasonable, 

vt. greater. than. 2. knots)  and 
not  test[I]  is  in  (gyro. cal,  navigate) 

::CONCLUSION  action(ljs  "See  the  shop  supervisor.  Normally  this  message 

occurs  only  when  the  IMU  is  in  gyro. cal  or 
navigate" 

END. DEFINE 

DEFINE  RULE  rule033 
:: APPLIED. TO  I: IMU 
:: PREMISE  check. position! I]  and 

north. south. or. east .vest (I] 

: : CONCLUSION  wait . for. platform. to. slew) I] 

END. DEFINE 

DEFINE  RULE  rule034 
:: APPLIED. TO  I. -IMU 

::PRENISE  vai t . for . platform. to. slew(I ]  and 

velocities . changed . d i rec  t ions [ I ] 

:  .-CONCLUSION  begin 

replace. faulty .component (1) ; 
fault (I)  s  corresponding. velocity. meter; 
end 

END.  DEFINE 

DEFINE  RULE  rule035 
APPLIED. TO  I:IMU 

::PRENISE  wait. for. platform. to. slew[I]  and 

not  velocities. changed .directions!!] 

: ;CONCLUSION  check. gyro. circuit!!] 

END. DEFINE 

DEFINE  RULE  rule036 
:: APPLIED. TO  I:IMU 
::PRENISE  check. position(I]  and 

not  north. south. or. east. west{I] 

: : CONCLUSION  check. gyro.circuit!!] 

END. DEFINE 

DEFINE  RULE  rule037 
APPLIED. TO  I:IMU 

::PRENISE  check. velocity. direction(I]  and 

north.south.or.east.vestll] 

:: CONCLUSION  begin 

replace. faulty. component!!] ; 
fault]!]  =  corresponding. velocity. meter; 
end 


END. DEFINE 
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DEFINE  RULE  rule038 
.•••APPLIED.  TO  I:IMU 

::PREHISE  check. velocity.dlrectionll)  and 
not  north. south. or. east. vest[I] 
: tCONCLUSION  check. for. level. platforffl(I] 

END. DEFINE 


DEFINE  RULE  rule039 
APPLIED. TO  I:IMU 

::PREMISE  check. for. level. plat£orm[I]  and 
not  azimuth.equal.zero[I j 
: :CONCLUSION  check. velocity. meterfi] 

END. DEFINE 
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DEFINE  RULE  ruleOAO 
:: APPLIED. TO  I:IMU 

;:PREMISE  check. velocity. meter{IJ  and 
f aul ty . velocity . me  ter ( I J 
:: CONCLUSION  begin 

replace. faulty .component (I] ; 
fault[I]  =  corresponding. velocity. meter ; 
end 

END. DEFINE 
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DEFINE  RULE  ruleOAl 
:: APPLIED. TO  IsIMU 

PREMISE  check. for . level. platform{ I }  and 
azimuth. equal. zero( 1 1 
: : CONCLUSION  check.gyro. circuit [I] 

END. DEFINE 


DEFINE  RULE  rule042 
APPLIED. TO  I;IMU 

::PREHISE  check. velocity. meterfi]  and 
not  faulty. velocity. meterfi] 
: tCONCLUSION  check.gyro.circuitf I] 

END. DEFINE 


/*  */ 
/*  CHECK  GYRO  CIRCUIT  ROUTINE  */ 

/*  This  routine  is  used  for  several  different  error  messages  including  */ 
/*  velocity  unreasonable,  vt.  greater  than  2  knots,  imu  major,  and  */ 
/*  plat  stab  abort.  */ 


DEFINE  RULE  rule043 
ttAPPLIED.TO  ItIMU 

:: PREMISE  check.gyro.circuitf I]  and 

speed . control .signal . good  f I ] 
: tCONCLUSION  check. gyro. run. voltagef I] 
END. DEFINE 
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DEFINE  RULE  rule044 
:: APPLIED. TO  I:IMU 

::PR£MISE  check. gyro. run. voltagefi]  and 
gyro . run . voltage . good [ I ] 

: :CONCLUSION  check. pick. off .signals[I] 

END. DEFINE 

DEFINE  RULE  rule045 
:: APPLIED. TO  I:IMU 

::PREHISE  check.pick.of f .signals{I]  and 

pick.of f .signals.good(II 

: : CONCLUSION  check. pick.of f. signals. while. gyros. not . running! I ] 

END. DEFINE 

DEFINE  RULE  rule046 
APPLIED. TO  I:IMU 

::PREHISE  check. pick. off .signals(I]  and 

not  pick. off .signals. goodfl] 

:: CONCLUSION  begin 

replace. faulty. component(I ] ; 
faultll]  =  corresponding. gyro; 
end 

END. DEFINE 

DEFINE  RULE  rule047 
APPLIED. TO  I:IHU 

: '.PREMISE  check. pick.of f. signals. while. gyros. not .  running(I ]  and 

not  pick. of f . signals .while . gyros . not . running . good [ I ] 

;  .'CONCLUSION  begin 

replace . f aul ty . componen  t ( I ] ; 
fault (I I  3  corresponding. gyro; 
end 

END. DEFINE 

DEFINE  RULE  rule048 
.'.'APPLIED.  TO  I:IMU 

::PREHISE  check. pick. off .signals. while. gyros. not. running[I]  and 

pick. of f . signals .while .gyros . no t . running. good [ I ] 

: : CONCLUSION  moni tor . speed . control . for . bl4 . and . up ( I ] 

END. DEFINE 

DEFINE  RULE  rule049 
APPLIED. TO  I;IMU 

:: PREMISE  moni tor . speed. control . for . bl4. and. up[ I ]  and 
speed.control. for . bl4.and.up.good[I ] 

::CONCLUSION  run. next. test[I] 

END. DEFINE 
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DEFINE  RULE  rule050 
APPLIED. TO  ItIMU 

:: PREMISE  moni tor. speed. control. for. bl4. and. up( I]  and 

no t  speed . con  t r ol . f or . bl4 . and . up . good [II 
:: CONCLUSION  begin 

replace. faul ty. component (II ; 
fault(II  =  corresponding. gyro; 
end 

END. DEFINE 

DEFINE  RULE  rule051 
APPLIED. TO  I;IMU 

:: PREMISE  check. gyro. run. voltage! I [  and 

not  gyro.run. voltage.good(Il 
: : CONCLUSION  interchange.psl.and.ps2(lj 
END. DEFINE 

DEFINE  RULE  rule052 
:: APPLIED. TO  IrlMU 

:: PREMISE  interchange.psl.and.ps2[Il  and 

problem. follows . power . supply . card [ I ) 

;  .-CONCLUSION  begin 

replace .faulty. component ( I ] ; 
fault [I]  =  corresponding. power. supply. card 
end 

END. DEFINE 

DEFINE  RULE  rule053 
APPLIED. TO  I:IMU 

;:PREM1SE  interchange. psl. and. ps2(Il  and 

not  problem . follows . power . supply . card [ 1 1 
.-!  CONCLUSION  begin 

replace . faul ty . component ( I ] ; 
faulttl]  =  corresponding. gyro; 
end 

END. DEFINE 

DEFINE  RULE  rule054 
APPLIED. TO  I:IMU 

;:PREMISE  check.gyro.circuitflj  and 

not  speed.control.signal.good[I] 

;  .-CONCLUSION  interchange. speed. control. cards[Il 
END. DEFINE 


DEFINE  RULE  rule055 
:: APPLIED. TO  I:IMU 

::PREHISE  interchange. speed.control. cards! I]  and 

no t  problem . follows . speed . con t rol . card [ I ] 

: '.CONCLUSION  begin 

replace . f aul cy . component [ I ] ; 
fault(I]  s  corresponding. gyro; 
end 

END. DEFINE 

DEFINE  RULE  rule056 
APPLIED. TO  I;IMU 

: : PREMISE  interchange . speed . control . cards ( I ]  and 

problem . follows . speed . control . card ( I ] 

:: CONCLUSION  begin 

replace. faulty.componentll ) ; 
fault [I]  s  corresponding. speed. card; 
end 

END. DEFINE 

DEFINE  RULE  rule057 
::  APPLIED.  TO  I.'IMU 
:: PREMISE  run. next. test {I]  and 

not  next . test .good(I ] 

: : CONCLUSION  check. speed. stabilityl I] 

END. DEFINE 

DEFINE  RULE  ruleOSS 
APPLIED. TO  I:IHU 
!:PREHISE  run.next . test(I I  and 

next . test .good(I ] 

!! CONCLUSION  run.scorsby. testjl] 

END. DEFINE 

DEFINE  RULE  rule059 
:: APPLIED. TO  I;IMU 
:: PREMISE  run.scorsby. testll]  and 

not  scorsby.goodjl) 

: :COMCLUSION  check. speed. stability(I] 

END. DEFINE 

DEFINE  RULE  rule060 
:: APPLIED. TO  I:IMU 
:: PREMISE  run.scorsby. test (I]  and 

scorsby.good(I] 

:: CONCLUSION  begin 

action{I]  *  "Testing  is  complete.  All  inputs  indicate 
this  testing  is  good"; 
faultfl]  >  none; 
end 

END. DEFINE 
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Appendix  B:  The  Deep. Diagnose  Control  Block 


■ 


f: 


I 


/*  DEEP  DIAGNOSE  */ 
/*  This  Control  Block  is  the  Inference  Engine  of  this  portion  of  the  */ 
/*  program.  Although  it  is  based  on  a  program  from  the  S.l  manual,  it  */ 
/*  has  been  greatly  enhanced.  The  control  block  determines  the  fault  */ 
/*  of  the  system  by  searching  for  a  bad  input  to  the  current  system.  */ 
/*  If  one  is  found,  the  control  block  is  called  with  the  component  */ 
/*  responsible  for  the  bad  input  as  its  argument.  This  continues  until  */ 
/*  a  component  is  found  with  a  bad  output,  but  no  bad  inputs.  It  is  */ 
/*  then  determined  if  this  component  has  subcomponents.  If  so,  the  */ 
/*  subcomponents  are  built  and  the  subcomponents  are  diagnosed.  When  */ 
/*  a  component  with  a  bad  output,  good  inputs,  and  no  subcomponents  ,  */ 


/*  the  component  is  identified  as  the  faulty  component  and  the  search  */ 
/*  is  terminated.  This  algorithm  has  been  enhanced  to  ensure  that  the  */ 
/*  highest  risk  components  (that  is,  the  components  most  likely  to  be  */ 
/*  at  fault)  are  tested  first  followed  by  components  with  medium  risk,  */ 


/*  then  those  with  low  risk.  In  the  case  of  components  with  multiple  */ 
/*  inputs,  the  high  risk  inputs  will  be  tested  first.  This  is  due  to  */ 
/*  the  ordering  of  the  Rules  that  cause  the  components  to  be  tested.  */ 
/*  The  Arguments  for  this  control  block  are:  */ 
/*  Component  -  The  component  currently  under  consideration.  */ 
/*  Start  -  The  first  component  in  the  current  path  being  tested.  */ 
/*  Finish  -  The  last  component  in  the  current  path  being  tested.  */ 
/*  (Initially,  a  dummy  variable  since  the  end  is  not  known)*/ 
/*  P:Path  -  The  level  of  the  current  search.  This  dictates  whether  a*/ 
/*  component  will  be  tested  immediately.  Initially,  the  */ 
/*  search  level  of  the  path  will  be  set  to  high  level  and  */ 
/*  only  components  with  high  risk  or  multiple  inputs  will  */ 
/*  be  tested.  If  the  fault  is  not  found,  the  search  level  */ 


/*  will  be  lowered  to  medium  level,  then  finally  low  level.*/ 


DEFINE  CONTROL. BLOCK 
: : INVOCATION 
'.•.ARGUMENTS 


:;BODY 
begin 

display  new.line()! 

new.lineO!  " 
new.lineO!  " 

new.lineO  • 

new.lineO! 
new.lineO!  " 
Case  search. level! p] 
high. level: 


DEEP. DIAGNOSE 
internal 

COMPONENT: i mu. component , 
START: i mu. component , 
FINISH: imu. component , 
p:path 


Deep  Diagnose  was  invoked  with"! 
component  >  "!  instance. trans(component) ! 
start  >  "!  instance. trans(start)  ! 
finish  3  "! instance. trans( finish) ! 
level  =  "!  search. level ( p] ; 
of 


/*  In  a  high  level  search  end  will  always  equal  0  because  as  soon  as  an 
end 
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point  is  found,  level  of  search  will  be  changed  to  medium.  Also,  the 
output  of  start  is  always  bad.  A  critical  test  component  is  defined  as 
one 

that  is  high  risk  or  has  multiple  inputs.  The  pseudo  code  for  high 
level  is 

if  not  critical. test(component)  and  not  end.point(component} 
then  call  deep  diagnose(componentl, start, 0, high) 

if  not  critical. test(component)  and  end.point(component) 
then  call  deep. diagnose(start, start, component, med) 

if  critical. test(component)  and  output. test. ok(component) 
then  call  deep. diagnose(start, start, component, med) 

if  critical. test(component)  and  not  output. test. ok(component) 
then  determine  bad. input (component ) 

if  bad. input  exists  call 

deep . d iagnose( componen  1 1 , component 1 , 0 , high ) 

if  bad. input  does  not  exist  determine  if  component 

has  subcomponents.  If  so,  call 

deep . d iagnose ( componen  1 2 , componen  1 2 , 0 , high ) 

if  component  does  not  have  subcomponents  create 

instance  fault  with  name.of(component].  */ 

begin 

determine  critical. tes t( COMPONENT ] ; 
if  not  critical. test(COMPONENT) 
then  begin 

if  end. point (COMPONENT] 
then  begin 

if  exists(med:path|search.level(med]  is 
med. level) 

then  invoke  deep. diagnose(start , start , component , med) 
end 

else  begin 

if  exists(C0NP0NENTl: imu. component , 

high: path  I  connected. to(C0MP0NENTl , COMPONENT]  known 
and  search. level (high]  is  high. level) 
then  invoke  deep. diagnose(componentl, start, finish, high) 
end 
end 

else  begin 

determine  output . test . ok( componen t ] ; 
if  output. test. ok (component] 
then  begin 

if  exists(med:path|search.level(med]  is  med. level) 
then  invoke  deep. diagnose(start , start , component , med) 
end 

else  begin 

determine  bad . input (COMPONENT ] ; 
if  bad. input (COMPONENT]  definite 


■ 


I 


c 


I 


then  begin 

if  exists(COHPONENTl: imu. component , high: path  I 
connected. tofCOHPONENTl, COMPONENT]  » 
bad. input [COMPONENT]  and 
search. level (high)  is  high. level) 
then  invoke 

deep . d iagnose( componen  1 1 , componen  1 1 , £ inish .high ) 

end 

else  begin 

if  has. subcomponent (COMPONENT] 
then  begin 

Invoke  build. subcomponent (COMPONENT) ; 
if  exists  (C0MP0NENT2: i mu. component , 
high : path , d : dummy | 

same . output . as ( COMPONENT , COMPONENT2 ] 
and  search. level [high]  is  high. level) 
then  begin 
invoke 

deep . diagnose ( C0HP0NENT2 , C0MP0NENT2 , d , high ) ; 

end 


end; 

end; 


end 

else  display  new.line()!  "The  fault  was  found"! 
"  to  be  the  "  !  ins tance. name ( COMPONENT) ; 

end; 

end; 


med. level : 

/*  There  are  two  ways  med  is  called  from  the  high  level. 

First,  if  the  end. point  is  found  so  that  the  fault  has  been 
isolated  between  either  start  and  end. point  or  a  high  and  an 
endpoint.  Second  if  it  has  been  isolated  between  two 
endpoints.  Either  way,  a  start  and  an  end  are  known.  Also, 
the  output  of  start  is  known  to  be  bad.  End  is  never  0.  There 
will  be  no  high  risk  or  multiple  input  components  in  the 
path.  */ 

/*  if  risk( component)  is  low  and  not  component  >  end  then 
call  deep  diagnose(componentl, start, end, med)  */ 

/*  if  risk(component)  is  low  and  component  >  end  then 
call  deep  diagnose(start, start, end, low)  */ 

/*  if  risk(cofflponent)  is  med  and  output. test. ok(component) 
then  call  deep. diagnose(start, start, component, low)  */ 

/*  if  risk< component)  is  med  and  not  output . test .ok(component) 
then  determine  bad. input (component]  */ 

/*  it  bad. input  exists  call 

deep . d i agnose( componen  1 1 , componen  1 1 , 0 , med )*/ 
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/*  if  bad. input  does  not  exist  determine  if  component 
has  subcomponents.  If  so,  call 
deep. diagnose (component 2, component 2,0, high)  */ 

/*  if  component  does  not  have  subcomponents  create 
instance  fault  vith  name.of [component ] .  */ 


begin 

if  risk( component ]  is  low 
then  begin 

if  finish  »  component 
then  begin 

if  exists(lov:path|search.level[lov]  is  low. level) 
then  invoke  deep. diagnose(start, start, finish, low) 
end 

else  begin 

i f  exis ts (COHPONENTl : imu . componen t , med : pa th | 
connected. to [COMPONENTl, COMPONENT  1  known  and 
search. level (med ]  is  med. level) 
then  invoke  deep. diagnose(cofflponentl, start, finish, med) 
end 
end 

else  if  output. test. ok [COMPONENTl 
then  begin 

if  exists(low:path|search.level[low]  is  low. level) 
then  invoke  deep. diagnose(start, start, component, low) 
end 

else  begin 

determine  bad. input[ COMPONENT ] ; 
if  bad. input (COMPONENT)  definite 
then  begin 

i f  exis ts(COMPONENTl t imu . componen t , d ; dummy , 

med : pa  th I  connected . to[ COMPONENTl , COMPONENT )  = 
bad. input [COMPONENT]  and  search. level [med] 
is  med. level) 

then  invoke  deep. diagnose<componentl,componentl,d, med) 
end 

else  begin 

if  has. subcomponent [COMPONENT] 
then  begin 

i nvoke  build. subcomponen t ( COMPONENT ) ; 
if  exists  (C0NP0NENT2: imu. component, 
d: dummy, high: path  I 

same . ou  t  pu  t . as [ COMPONENT , C0MP0NENT2 ] 
and  search. level[high]  is  high. level) 
then  invoke 

deep . diagnose(C0MP0NENT2 , C0MP0NENT2 , d , high) 
end 

else  display  new.lineO!  "The  fault  was  found"! 

"  to  be  the  "  !  instance. name(COMPONENT) ; 

end 

end 
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low. level: 

/*  risk  is  known  to  be  low.*/ 

/*  input  known  to  be  single.*/ 

/*  the  output  is  bad  */ 

/*  if  bad. input  exists  call 
deep . diagnose( component  1 , component  1 , 0 , low )  */ 

/*  if  bad. input  does  not  exist  determine  if  component 
has  subcomponents.  If  so,  call 
deep . d i agnose ( componen 1 2 , componen t2,0,high)  */ 

/*  if  component  does  not  have  subcomponents  create 
instance  fault  with  name. of [component ] .  */ 


begin 

determine  bad. input [COMPONENT [ ; 
if  bad. input [COMPONENT]  definite 
then  begin 

if  exists( COMPONENTl : i mu . componen t , 1 ow ; pa t h | 
connected . to ( COMPONENTl , COMPONENT ]  = 
bad. input [COMPONENT]  and  search. level] low]  is 
low. level) 

then  invoke  deep. diagnose(componentl,componentl, finish, low) 
end 

else  begin 

i f  has . subcomponen t [ COMPONENT ] 
then  begin 

i nvoke  build. subcomponen t ( COMPONENT } ; 
if  exists  (C0MP0NENT2: i mu. component ,d: dummy, 

h  igh :  pa  t  h  I  same .  ou  t  pu  t .  as  ( COMPONENT ,  C0NP0NENT2  ] 
and  search. level [high]  is  high. level) 
then  invoke  deep. diagnose(C0MP0NENT2,C0NP0NENT2,d, high) 
end 

else  display  new.line()!  "The  fault  was  found"! 

"  to  be  the  "  !  instance. name(COMPONENT) ; 
end 
end 
end; 
end; 

END. DEFINE 
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Appendix  P:  Code  For  The  Blended  Diagnostic  Systen 


/*  The  Blended  Diagnostic  System  (BDS)  */ 

/*  */ 

/*  Coder:  ILt  Jim  Skinner  */ 

/*  Last  Update:  23  Aug  88 

/*  */ 

/*  Description:  The  Blended  Diagnostic  System  BDS  has  been  designed  to  */ 
/*  isolate  faults  in  the  Dual  Miniature  Inertial  Navigation  System  */ 

/*  (DHINS)  Inertial  Measurement  Unit  (IMU).  The  expert  system  begins  by  */ 
/*  querying  the  user  for  the  error  message  reported  by  the  automatic  */ 

/*  test  equipment  (ATE),  and  then  guides  the  technician  through  the  */ 

/*  tests  necessary  to  determine  the  fault  in  the  IMU.  There  are  a  total  */ 

/*  of  62  possible  error  messages  that  can  be  reported  by  the  ATE.  The  */ 

/*  possible  faults  are  the  38  shop  replaceable  units  contained  in  the  */ 

/*  IMU.  */ 

/*  The  knowledge  that  BDS  uses  to  determine  the  fault  is  from  two  */ 

/*  sources;  the  first  is  the  shallow  knowledge  collected  from  the  */ 

/*  expert  technician  during  knowledge  engineering  sessions.  The  second  */ 

/*  source  of  knowledge  is  the  deep  knowledge  obtained  by  constructing  a  */ 
/*  model  of  the  system  based  on  structural  knowledge  contained  in  the  */ 
/*  TOs.  */ 

/*  Status:  The  code  for  BDS  was  written  with  an  emphasis  on  */ 

/*  maintainability  so  that  the  system  could  continue  to  grow  after  */ 

/*  final  delivery.  The  shallow  portion  of  the  code  covers  all  of  the  */ 

/*  62  error  messages.  The  Deep  portion  of  the  code  is  complete  for  four  */ 

/*  of  these  messages.  They  are:  xy  speed  control,  yz  speed  control,  */ 

/*  velocity  unreasonable,  and  vt  greater  than  2  knots.  The  intent  of  */ 

/*  the  coder  is  that  this  system  will  grow  to  be  complete  in  both  */ 

/*  shallow  and  deep  knowledge.  */ 

/*  */ 

/*  This  system  was  developed  in  S.l.  The  structure  of  the  code  is  as  */ 
/*  follows:  */ 

/*  */ 

/*  I.  Shallow  Reasoning  */ 

/*  a.  Control  Blocks  */ 

/*  b.  Classes  */ 

/*  c.  Attributes  *  */ 

/*  d.  Value  Hierarchies  */ 

/*  e.  Rules  **  */ 

/*  */ 

/*  II.  Deep  Reasoning  */ 

/*  a.  Control  Blocks  */ 

/*  b.  Classes  *  */ 

/*  c.  Attributes  *  */ 

/*  d.  Value  Hierarchies  */ 

/*  e.  Rules  */ 

/*  */ 

/*  *  In  alpabetical  order.  */ 

/*  */ 

/*  **  Rules  25,  35,  36,  38,  and  41  provide  the  transition  from  */ 

/*  shallow  to  deep  reasoning.  */ 


/*  */ 

/*  Part  I.  Shallow  Reasoning  */ 

/*  */ 

/*  The  main  attributes  determined  by  this  program  are:  */ 

/*  */ 

/*  1.  Fault:  Fault  is  the  component  that  the  expert  system  determined  */ 

/*  as  responsible  for  the  error  message  received.  Fault  is  */ 

/*  determined  (in  some  cases)  after  action  is  recommended.  This  */ 

/*  forces  Fault  to  default  to  not. determined  if  no  rule  concludes  */ 

/*  its  value.  Fault  allows  an  operator  to  query  S.l  about  previous  */ 

/*  faults  in  an  IMU  and  provides  a  "hook"  for  future  programs  to  */ 

/*  store  previous  faults  in  a  historical  database  through  the  use  */ 

/*  of  S.l  external  functions.  */ 

/*  */ 

/*  2.  Action:  Action  is  the  recommended  course  of  action  for  the  */ 

/*  operator  to  take  in  order  to  correct  the  fault.  */ 

/*  */ 

/**1i**1i*********1t***ii***1t*iiic*****1i**-k******ii-ti********1t*****i,it**it********/ 

/*  */ 

/*  CONTROL  BLOCK  DEFINITIONS  */ 

/*  */ 

/*  */ 

/*  The  first  Control  Block  is  the  top. level  control  block  invoked  first*/ 

/*  when  a  consultation  is  started  */ 

DEFINE  CONTROL. BLOCK  ABOUT. IMU 

: : INVOCATION  top-level 

::TRANSLATION  "diagnose  faults  in  the  IMU  " 

:  .'BODY 
begin 

vars  I:imu; 

display  spaces(25)  !  "THE  DHINS  FAULT  ADVISOR"! 
new.lineO; 

create. instance  imu  called  I  with 
begin 

name.of(IJ  -  "IMU"; 
has . subcomponent [ I | ; 
critical. test(I] ; 
output. test .ok[ I] <-1.0>; 
end; 

determine  error.message[I ] ; 
determine  action(I]; 
if  action[I]  =  "Begin  deep  diagnosis" 
then  invoke  DIAGNOSE. IMU. FAULT( I) 
else 
begin 

invoke  display. recommendations(I) ; 
determine  fault[I]; 

end; 

end 

END. DEFINE 
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/itiraifitiiniiit**************************************************************/ 


/*  An  internal  control  block  used  to  display  the  values  concluded  for  */ 
/*  the  action  attribute  */ 


DEFINE  CONTROL. BLOCK 
; : INVOCATION 
:: ARGUMENTS 
:  -.TRANSLATION 
::BODY 
begin 

display  nev.line() 
end 

END. DEFINE 


display. recommendations 

internal 

I:IMU 

"Display  recommended  action 


capitalize<Action(I])  ! 


/*  CLASSES  */ 
/*  "IMU"  is  the  only  class  in  the  shallow  reasoning  system.  */ 
/*  */ 


DEFINE  CLASS 
:: NUMBER. INSTANCES 
:: PRINT. ID 
: ; CLASS. TRANSLATION 
:: PLURAL . CLASS . TRANSLATION 
: :  BLAND .  INSTANCE .  TRANSUTION 
: : FULL. INSTANCE. TRANSLATION 
ANNOUNCEMENT 


END. DEFINE 


IMU 

1 

"IMU  #" 

"an  IMU  " 

"the  IMUs  " 

"the  IMU  " 

"this  IMU" 

nev.lineO  f  indentO  J  "This  IMU  will  be 
referred  to  as;  "  I 

instance. name(IMU)  !  nev.lineO  !  outdentO 


/*  */ 

/*  MAIN  ATTRIBUTES  */ 

/*  */ 

/*  The  following  attributes  are  the  main  attributes  in  the  program.  */ 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
;:TYPE 

: ; MULTIVALUED 
LEGAL. VALUES 


error. message 

IMU 

text 

false 

error .messages 


/*  Legal  values  use  error. messages  value  hierarchy  */ 

: :LEGAL. MEANS  (query. user) 

: : DETERMINATION . MEANS  (query . user) 

PROMPT  "What  error  message  is  displayed 

: :TRANSLATION  "the  displayed  IMU  Error  Message" 

END. DEFINE 


?" 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
: :TYPE 

: : MULTIVALUED 
:: LEGAL. VALUES 
/*  Legal  values  use  faults 
:: LEGAL. MEANS 
;; DEFAULT. VALUES 
: : DETERMINATION . MEANS 
: : TRANSLATION 
END. DEFINE 


fault 

IMU 

text 

false 

possible. faults 
value  hierarchy  */ 

{try. rules) 

(not .determined) 

(try. rules) 

"the  fault  of  the  problem" 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
:  .'TYPE 

; ; MULTIVALUED 
:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
TRANSLATION 
END. DEFINE 


action 

ifflu 

text 

false 

{try. rules) 

(try. rules) 

"the  recommendations  for  fixing  the  problem" 


/*************★************************************************★******★*/ 


/*  */ 

/*  REMAINING  ATTRIBUTES  */ 

/*  */ 

I*  The  remaining  attributes  are  listed  in  alphabetical  order.  */ 

/*  */ 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
: tTYPE 

:: LEGAL. MEANS 
! : DETERMINATION. MEANS 
!  ’.PROMPT 

::TRANSUTION 

END. DEFINE 


able. to. restart 
ifflu 

boolean 
(query. user) 

(query. user) 

"Install  the  diagnostic  cap  and  attempt  to 
restart  the  test.  Is  a  restart  possible?" 
"all  three  axes  "  !  verb("are",  "are  not")  f 
"  near  zero" 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
::TYPE 

:: LEGAL. MEANS 
: : DETERMINATION . MEANS 
: : PROMPT 


:: TRANSLATION 
END. DEFINE 


all. three. axes. near. zero 
imu 

boolean 
(query. user) 

(query .user) 

"Check  the  A  to  D  converter.  Are  all  three 
axes  near  zero?" 

"all  three  axes  "  !  verb("are",  "are  not")  ! 
"  near  zero" 
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DEFINE  ATTRIBUTE 
:: DEFINED. ON 
: :TYPE 

:  .'LEGAL. VALUES 
:: LEGAL. MEANS 
:  '.DETERMINATION. MEANS 
:: PROMPT 


; ; TRANSLATION 
END. DEFINE 


angle . occurs . f i r s  t . on 

imu 

text 

{xy.pickoff,  yz.pickoff) 

{query. user) 

(query. user) 

"Monitor  test  points  77,  79,  and  81  (gyro 
pickoffs).  Does  the  excess  angle  occur  first 
on  the  XY  gyro  pickoff  or  the  YZ  gyro 
pickoff?" 

"the  excess  angle  " 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
: :TYPE 

:: LEGAL. MEANS 
: : DETERMINATION . MEANS 
;; TRANSLATION 
END. DEFINE 


at  tempt. res  tart 
imu 

boolean 
{try. rules) 

(try. rules) 

"attempt  a  restart" 


DEFINE  ATTRIBUTE 
DEFINED. ON 
!:TYPE 

:: LEGAL. MEANS 
: : DETERMINATION . MEANS 
.'!  PROMPT 


TRANSLATION 
END. DEFINE 


azimuth. equal. zero 
imu 

boolean 
{query. user) 

(query. user) 

"(iheck  the  A-D  converter  on  the  test  station. 

Is  the  platform  level  (azimuth  «  0)?" 

"the  platform  "  !  verb("  is",  "is  not") 

!  "  level" 


DEFINE  ATTRIBUTE 
: : DEFINED. ON 
: :TYPE 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
:: PROMPT 

: : TRANSLATION 

END. DEFINE 


cables. good 
imu 

boolean 
{query. user) 

(query. user) 

"Check  cables  Jl  and  J2.  Are  the  cables 
good?" 

"cables  Jl  and  J2  "!verb("are","are 
not") ! "good" 
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raFINE  ATTRIBVrB 
::DBFINBD.ON 
::TTPB 

:: LEGAL. MEANS 
: :I»TERMINATION. MEANS 
::PRONPT 


:  '.TRANSLATION 
END.DBFINE 


case .rotation. noraal 
iau 

boolean 
(query. user) 

(query. user) 

"^11  the  gyro  power  supply  cards.  DO  NOT 
TURN  THE  IMU  OFF!  Next,  put  the  diagnostic 
cap  on.  After  ten  ainutes,  check  the  case 
for  rotation  at  test  points  77,  79,  and  81. 
Is  the  rotation  noraal?” 

"the  case  rotation”  !  verb(*is","is  not")!  ” 
noraal” 


n 


l»FINE  ATTRIBUTE 
:  tlXBFINBD.ON 
: :TTPE 

:: LEGAL. VALUES 
:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
:: PROMPT 

: : TRANSLATION 
END.DBFINE 


change 

iau 

text 

(sudden. change,  gradual.drif t) 

(query. user) 

(query. user) 

"Bow  did  the  RMS  get  out  of  spec?  Vas  it  a 
sudden  change  or  a  gradual  drift?” 

”hov  the  RMS  got  out  of  spec” 


1»FINE  ATTRIBUTE 
_  :: DEFINED. ON 

■  : :TTPB 

:: LEGAL. MEANS 
: : DETERMINATION . MEANS 
: : TRANSLATION 
END.DBFINE 


check. a . to . d . conver ter . no t . caged 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  A-D  converter  should  be  checked” 


DEFINE  ATTRIBUTE 
: '.DEFINED. ON 
: :TTPB 

: '.LEGAL. MEANS 
: : DETERMINATION. MEANS 
'.  :TRANSLATION 
END.DBFINE 


check . a . to . d . converter . servo . d i sable 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  A-D  converter  should  be  checked” 


DEFINE  ATTRIBUTE 
::DBFINBD.ON 
! :TTPB 

:: LEGAL. MEANS 
:  '.DETERMINATION. MEANS 
:  '.TRANSLATION 
END.IKFINE 


check.a. to. d. conver ter. z. stab 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  A-D  converter  should  be  checked” 


I 


( 
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obfuib  attribvtb 

::DBFIIIBD.ON 
: :TTPB 

: :LBGAL.HEAMS 
:  :DBTEUIIIIATION.  MEANS 
: : TRANSLATION 

END. DEFINE 


check. cables 
iau 

boolean 
(try. rules} 

(try. rules) 

"the  cables  aay  be  faulty  and  should  be 
checked" 


DEFINE  ATTRIBITTE 
:tI»FINED.ON 
::TTPB 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: :TRANSLATION 
BND.KFINE 


check. digi tal . processor 
iau 

boolean 
(try. rules) 

(try. rules) 

"check  the  digital  processor* 


KFINE  ATTRIBUTE 
::DBFINED.ON 
:;TTPE 

:: LEGAL. MEANS 
: : DETERMINATION . KEANS 
: : TRANSLATION 
END. DEFINE 


check. for . case . rotation 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  IHU  should  be  checked  for  case  rotation" 


DEFINE  ATTRIBUTE 
::i»FINBD.ON 
:;TTPB 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: : TRANSLATION 
END. DEFINE 


check . for . level . plat  fora 
iau 

boolean 
( try. rules) 

(try. rules) 

"check  to  see  if  the  platfom  is  level" 


DEFINE  ATTRIBUTE 
::DEFINED.ON 
::TTPE 

: zLEGAL.NEANS 
: :DBTERMINATIOM. MEANS 
:  :TRANSLATION 
END. DEFINE 


check.gyro. circuit 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  gyro  circuit  should  be  checked” 


DEFINE  ATTRIBUTE 
::DBFINED.ON 
; iTTPR 

:: LEGAL. MEANS 
: : DETERMINATION . MEANS 
: :TRANSLATION 
END. DEFINE 


check . gyro . run .volt age 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  gyro  run  voltage  should  be  checked" 


c 


DEFINE  ATTRIBUrTE 
::DEFINED.ON 
s :TTPE 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: rTRANSLATlON 
EM>.  DEFINE 


check. gyro. torquers 
imi 

boolean 
(Cry. rules} 

(try. rules) 

"^eck  the  gyro  torquers” 


DEFINE  ATTRIBUTE 
:  .'DEFINED.  (W 
. 'TYPE 

:: LEGAL. MEANS 
:  '.DETERMINATIMI. MEANS 
: : TRANSLATION 

END. DEFINE 


check.eeter.el.positi jn.ll 
iau 

boolean 
(try. rules) 

(try. rules) 

”the  reading  on  neter  position  11  should 
be  checked” 


C 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
: :TTPE 

:: LEGAL. MEANS 
:  .'DETERMINATION. MEANS 
: : TRANSLATION 

END. DEFINE 


check. neter .■£. posi t ion . 21 
inu 

boolean 
(try. rules) 

(try. rules) 

”the  reading  on  neter  m2  position  21  should 
be  checked” 


■ 


l«FINE  ATTRIBUTE 
::DBFINBD.ON 
'.:TTPB 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: : TRANSLATION 
END. DEFINE 


check . pi ck . of £ . 8 ignals 
iau 

boolean 
(try. rules) 

(try. rules) 

”Che  pick  off  signals  should  be  checked” 


■  DEFINE  ATTRIBUTE 

'.;DBFINBD.ON 
: :TTPB 

.' .'LEGAL.  MEANS 

'. :  DETERMINATION.  MEANS 

t  '.TRANSLATION 

BND.DEFINB 


check . pi ck . of f . s ignals . vhi le . gyros . no t . runni ng 
iau 

boolean 
(try. rules) 

(try. rules) 

”Che  pick  off  signals  should  be  checked  while 
the  gyros  are  not  running” 


DEFINE  ATTRIBUTE 
::DEFINED.ON 
: :TTPB 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: :TRANSLATIOM 
BND.IKFINE 


check. posi tion 
iau 

boolean 
(try. rules) 

(try. rules) 

”the  position  should  be  checked” 


I 
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t 


DEFIHE  ATTRIBITTE 
:  tMFIIlED.ON 
•  sTHTPE 

itLBGAL. MEANS 
:  :DBTERMII1ATI0N.  MEANS 
: tTRANSLATION 
BND.IMSFINE 


check . power . cube 
ini 

boolean 
{tty. rules} 

(try. rules) 

"check  the  power  cube  " 


DEFINE  ATTRlBirrE 
::DBFINED.ON 
: :TTFE 

:: LEGAL. MEANS 
: :  IKTERNINATION. MEANS 
:  .-TRANSLATION 
END. DEFINE 


check. precision. current . network 
inj 

boolean 
(try. rules) 

(try. rules) 

"check  the  precision  current  network” 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
: ;TTPE 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: iTRANSLATION 
BMD.I»FINB 


check . resolver . exci tat ion 
ini 

boolean 
(try. rules) 

(try.  rules) 

"the  resolver  excitation  should  be  checked" 


I«FINE  ATTRIBUTE 
itKFINED.ON 
s iTTPE 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
t iTRANSLATION 

END. DEFINE 


check. resolver. signal. at . iau 
Ini 

boolean 
(try. rules) 

(try. rules) 

"the  resolver  signal  at  the  IMU  should  be 
checked" 


DEFINE  ATTRIBUTE 
iiDEFINED.ON 
: iTTPE 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
1 iTRANSLATION 

BND.KFINE 


check . resolver . signal . at . ncc 
ini 

boolean 
(try. rules) 

(try. rules) 

"the  resolver  signal  at  the  NCC  should  be 
checked” 


MFINE  ATTRIBUTE 
IiDEFINED.ON 
1 iTTPE 

1! LEGAL. MEANS 
1 ilffiTERNINATION. MEANS 
1 iTRANSLATION 


END.nFINE 


check. resolver . signal . on . different .station 
ini 

boolean 
(try. rules) 

(try. rules) 

"the  resolver  signal  at  the  IMU  should  be 
checked  while  the  IMU  is  on  a  different  test 
station” 
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»PIIIB  ATTRIBUTE 
:: DEFINED. ON 
::TTPB 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: :TRAMSLATION 
END. DEFINE 

ISFINE  ATTRIBUTE 
::DEFINED.ON 
:;TTPE 

:: LEGAL. MEANS 
: : DETERMINATION . MEANS 
: : TRANSLATION 
END. DEFINE 

DEFINE  ATTRIBUTE 
:: DEFINED. ON 
: :TTPE 

: '.LEGAL. MEANS 
: : DETERMINATION . MEANS 
: : TRANSLATION 
END. DEFINE 

DEFINE  ATTRIBUTE 
:  :l«FINEO.ON 
: :TTFE 

::  LEGAL. MEANS 
: : DETERMINATION. MEANS 
:: TRANSLATION 
END. DEFINE 

DEFINE  ATTRIBUTE 
: -.DEFINED.  ON 
:;TTFB 

:: LEGAL. MEANS 
: :  IWTERNINATION. MEANS 
: :TRANSLATION 
END. DEFINE 

DEFINE  ATTRIBUTE 
::DBFINED.ON 
::TTPB 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: : TRANSLATION 
END. DEFINE 


check. speed . control . signal 
inu 

boolean 
(try. rules) 

(try. rules) 

"the  speed  control  signal  should  be  checked" 


check . speed . s tabi 1 i ty 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  speed  stability  should  be  checked” 


check. test. point. 13 
iau 

boolean 
(try. rules) 

(try. rules) 

"check  test  point  13" 


check. test . point . 23 
iau 

boolean 
(try. rules) 

(try. rules) 

"check  test  point  23" 


check . veloc i ty . d i rec t i on 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  velocity  direction  should  be  checked” 


check . veloci ty . ae ter 
iau 

boolean 
(try. rules) 

(try. rules) 

"check  the  velocity  aeter" 
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DBFINB  ATTRIBVTB 
:  :DBFIIIED.ON 
i:TTPB 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: :TRANSLATION 
BND.MiFINE 


check. veloci ty . on. ncc 
imu 

boolean 
(try. rules) 

(try. rules) 

"check  the  velocity  on  the  ncc" 


DEFINE  ATTRIBUTE 
::DEFINED.ON 

• • ytpb 

:: LEGAL. MEANS 
: :  IKTERMINATION. MEANS 
:  '.TRANSLATION 
END. DEFINE 


check. VB. signal . on . ncc 
iau 

boolean 
(try. rules) 

(try. rules) 

"check  the  velocity  eeter  signal  on  the  NCC" 


inFINE  ATTRIBUTE 
:  :l»FINED.(Xf 
tjTTPE 

:: LEGAL. MEANS 
:  .'DETERMINATION. MEANS 
: : TRANSLATION 

END. DEFINE 


contact. te 
iau 

boolean 
(try. rules) 

(try. rules) 

"contact  the  T.E.  A  fault  is  suspected  in  the 
test  equipaent" 


1 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
I'.TTPR 

:: LEGAL. MEANS 
'. ! DETERMINATION. MEANS 
:: PROMPT 
.'  :TRANSLATION 

BND.DBFINE 


cooling. hose. is. connected 
iau 

boolean 
(query. user) 

(query. user) 

"Is  the  cooling  hose  connected?" 

"the  cooling  hose  "  !  verb("is",  "is  not")  ! 
"  connected" 


DEFINE  ATTRIBUTE 
tzDEFIMED.ON 
•TTPK 

: '.LEGAL.  MEANS 

: : DETERMINATION. MEANS 

.':PRONPT 

: : TRANSLATION 

END. DEFINE 


digi tal. processor. good 
iau 

boolean 
(query. user) 

(query. user) 

"Replace  the  digital  processor.  Is 
the  problea  still  present?" 

"the  digital  processor  "  I  verb("is",  "is 
not")  !  "good" 


i 
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DBFIHB  ATTRIBVTE 
::I«FINBD.WI 
::TTPB 

:: LEGAL.  MSAMS 
:  :I»TERMIIfATION.  MEANS 
:  :T11AMSLATIW 

END. DEFINE 


exchaynge. electronic .  control .  aaps 
leu 

boolean 
{try. rules} 

(try. rules) 

"the  electronic  control  aaps  should  be 
exchanged" 


DEFINE  ATTRIBUTE 
::DEFINED.ON 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: : TRANSLATION 
END. DEFINE 


exchange . speed .control. cards 
iau 

boolean 
{try. rules) 

(try. rules) 

"exchange  the  speed  control  cards" 


DEFINE  ATTRIBUTE 
::DEFINED.ON 
::TTPE 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
! :TRANSLATION 
END. DEFINE 


fault. found. continue. testing 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  fault  is  identified;  continue  testing" 


DEFINE  ATTRIBUTE 
::DBFINED.ON 
::TTPE 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
::PRONPT 
:  .'TRANSLATION 

END. DEFINE 


faulty.velocity.aeter 

iau 

boolean 
(query. user) 

(query. user) 

"Check  the  velocity  aeters.  Are  they  faulty?” 
"the  velocity  aeters  "  !  verb("are",  "are 
not")  !  "  faulty" 


DEFINE  ATTRIBUTE 
:;DBFINBD.ON 
: :TTPB 

:: LEGAL. MEANS 
:  iKTERNINATION.NEANS 
: :TRANSLATION 
END. DEFINE 


gyro. is. suspect 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  gyros  are  suspected" 


DEFINE  ATTRIBUTE 
::DBFINED.ON 
•TYPE 

:t LEGAL. MEANS 
: : DETERMINATION. MEANS 
:: PROMPT 

: : TRANSLATION 


gyro . run . vol tage . good 
iau 

boolean 
(query. user) 

(query. user) 

"Check  the  gyro  run  voltage.  Is  the  voltage 
good?" 

"the  gyro  run  voltage  "!verb("is","is  not")! 
"  good" 


END. DEFINE 


DBFINB  ATTRIBUTE 
::DBFINED.ON 
; :TTPB 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
;; PROMPT 


:  .'TRANSLATION 
END. DEFINE 


gyro . torquers . signals . good 
iau 

boolean 
(query. user} 

(query. user) 

the  cap  on  the  IMU  and  check  test  points 
26,  27,  and  28.  Are  the  gyro  torquers' 
signals  good?" 

"the  gyro  torquers  "!  verb("are",  "are  not  ") 
!  "good" 


DEFINE  ATTRIBUTE 
::DEFINED.ON 
::TTPE 

:  .'LEGAL. MEANS 
: : DETERMINATION. MEANS 
:: PROMPT 
:: TRANSLATION 

END. DEFINE 


iau . i n . caged . node 
iau 

boolean 
(query. user} 

(query. user} 

"Is  the  IMU  in  the  caged  aode?" 

"the  IMU  "  !  verb("is",  "is  not")  !  "in  the 
caged  aode" 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
::TTPE 

:: LEGAL. MEANS 
: :I»TERNINATION. MEANS 
:: PROMPT 


: ! TRANSLATION 
END. DEFINE 


iau . resolver . signal . good 
iau 

boolean 
(query. user) 

(query. user) 

"Check  the  resolver  signal  output  at 
the  IMU  with  the  cap  on  the  IMU. 

Is  the  signal  good?" 

"the  resolver  signal  output  at  the  IMU  "  ! 
verb("is",  "is  not")  1  "  good" 


DEFINE  ATTRIBUTE 
:;reFINED.ON 
:  :TTPE 

:: LEGAL. MEANS 
: :  ISTERMINATION. MEANS 
:: PROMPT 


::  TRANSLATION 


iau . resolver . s ignal . on . d i £ feren t . s ta t i on . good 
iau 

boolean 
(query. user) 

(query. user) 

"Move  the  IMU  to  another  station. 

Recheck  the  excitation  to  the  resolver. 

Is  the  signal  good?" 

"the  second  test  of  the  resolver  signal 
output  at  a  different  test  station"  ! 
verb("is",  "is  not")  !  "  good  " 


END. DEFINE 


4 


c 


DEFINE  ATTRIBUTE 
::DEFINBD.ON 
: :TTPB 

■  :: LEGAL. HBAHS 

: :1STERNINATI0N. MEANS 
:  .'TRANSLATION 

END. DEFINE 

DEFINE  ATTRIBUTE 
**  :: DEFINED.  (W 

: ;TTPE 

:: LEGAL. MEANS 
: '.  DETERMINATION .  MEANS 
:  '.TRANSLATION 

END. DEFINE 

DEFINE  ATTRIBUTE 
:: DEFINED. ON 

•  •  ytpb 

r  ::LEGAL.MEANS 

:: DETERMINATION . MEANS 
'. :  TRANSLATION 
END. DEFINE 

DEFINE  ATTRIBUTE 
DEFINED. ON 

■  : :TTPE 

: ’.LEGAL. MEANS 
: : DETERMINATION . MEANS 
: : TRANSLATION 

END. DEFINE 

■ 

DEFINE  ATTRIBUTE 
::DEFINED.ON 
: :TTFB 

:: LEGAL. KEANS 
: : DETERMINATION. MEANS 
'.  '.TRANSLATION 

END. DEFINE 

DEFINE  ATTRIBUTE 
::DEFINED.ON 
::TTPE 

:  .'LEGAL. MEANS 
t : DETERMINATION. MEANS 
: : TRANSLATION 
END. DEFINE 


interchange. electronic. control. aaps 

iBU 

boolean 
(try. rules) 

(try. rules) 

"the  electronic  control  aaps  should  be 
interchanged" 


interchange.giabal. rate. aaps 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  giabal  rate  aaps  should  be 
interchanged" 


interchange. psl . and . ps2 
iau 

boolean 
(try. rules) 

(try. rules) 

"PSl  and  PS2  should  be  interchanged" 


interchange. rate. aaps 
iau 

boolean 
(try. rules) 

(try. rules) 

"The  giabal  rate  aaps  should  be 
interchanged" 


interchange . speed . control . cards 
iau 

boolean 
(try. rules) 

(try. rules) 

"The  speed  control  cards  should  be 
interchanged" 


aonitor.pickoffs 

iau 

boolean 
(try. rules) 

(try. rules) 

"aonitor  the  pickoffs" 
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DEFINE  ATTRIBUTE 
:: DEFINED. ON 
8  sTTPB 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
:  .-TRANSLATION 
END. DEFINE 


■oni tor . speed . con  t  rol . for . bl4 . and . up 
Im 

boolean 
(try. rules) 

(try. rules) 

"aonitor  the  speed  control  for  B14  and  up" 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
;;TTPE 

:  .-LEGAL. VALUES 
LEGAL. MEANS 
: : DETERMINATION. MEANS 
::PROHPT 

-.  :TRANSLATION 
END. DEFINE 


■ost. drift 

iau 

text 

(longitude,  lattitude) 

(query. user) 

(query. user) 

"^at  contributes  aore  error  to  the  drift, 
longitude  or  lattitude?" 

"the  aain  contributor  to  the  drift" 


DEFINE  ATTRIBUTE 
: -.DEFINED. ON 
: :TTPE 

:: LEGAL. MEANS 
: : DETERMINATION . MEANS 
:  .-TRANSLATION 
END. DEFINE 


aove.to.aode.b 

iau 

boolean 
(try. rules) 

(try. rules) 

"the  IMU  should  be  aoved  to  Node  B" 


DEFINE  ATTRIBUTE 
.-:  DEFINED.  ON 
::TTPE 

.-:UGAL.  MEANS 
: : DETERMINATION . MEANS 
:: PROMPT 

:: TRANSLATION 


END.IffiFINE 


nev . digi tal . processor . corrects . problea 
iau 

boolean 
(query. user) 

(query. user) 

"Replace  the  digital  processor.  Did 
this  solve  the  problea?" 

"replacing  the  digital  processor  "  ! 
verb< "solved",  "did  not  solve")  !  "the 
problea" 


I«FINE  ATTRIBUTE 
.-:  DEFINED.  ON 

• • yypb 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
:: PROMPT 

.-  .-TRANSLATION 


next. test. good 
iau 

boolean 
(query. user) 

(query. user) 

"Run  the  next  test  on  the  Mode  A  station.  Did 
it  pass?” 

"the  next  test  "  !  verb("did",  "did  not") 

I  "  pass  on  the  Mode  A  test  station" 


END. DEFINE 


NSraiB  ATTRIBVTB 
:  :DBFIIIBO.ON 
isTTPB 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
:: TRANSLATION 

END. DEFINE 


noraal. response. to. operator. action 
inu 

boolean 
{try. rules) 

{try. rules) 

"the  error  nessage  "  !  verb("is",  "is  not")  ! 
"a  nornal  response  to  an  operator  acti< 


DEFINE  ATTRIBUTE 
::DEFINED.ON 
: :TTPE 

:: LEGAL. MEANS 

: : DETERMINATION. MEANS 

::PR(»fPT 

: : TRANSLATION 

END. DEFINE 


north. south. or. east. west 
inu 

boolean 
{query. user) 

{query. user) 

"Is  the  velocity  occurring  in  either  the 
North-South  or  the  East-Vest  direction?  " 
"the  direction  of  the  velocity  is 
either  North-South  or  Bast-Vest" 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
: ;TTPE 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
:  .'TRANSLATION 

END. DEFINE 


not. indication. of. fault 
inu 

boolean 
{try. rules) 

{try. rules) 

"the  error  nessage  "  I  verb("is  not"t 
"is")  I  "an  indication  of  an  INU  fault" 


DEFINE  ATTRIBUTE 
:!DEFINED.0N 
: jTTFE 

:: LEGAL. VALUES 
:: LEGAL. MEANS 
; : DETERMINATION. MEANS 
:: PROMPT 


:  .'TRANSUTION 
END.I»FINE 


nunber . of . axes . no t . zero 

inu 

text 

{one,  all) 

(query. user) 

(query. user) 

"Check  the  A  to  D  converter.  Is  one  axis 
significantly  further  fron  zero  than  the 
other  axes,  or  are  all  angles  off?" 
"nunber  of  axes  off" 
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I 


DBFINB  ATTRIBUTE 
.-.•DEFINED.  ON 
•TTPB 

: :LBGAL.NBANS 
:  .-ISTBRHINATION.  MEANS 
:: PROMPT 


:  -.TRANSLATION 


END. DEFINE 


one . axis . is . further . froe . xero 
im 

boolean 
(query. user} 

(query. user) 

"Check  the  A  to  D  converter.  Is  any  axis 
significantly  further  froe  zero  than  the 
other  axes?” 

"one  axis  "!verb("is","is  not")! 

”  significantly  further  froe  zero  than  the 
rest" 


WFINE  ATTRIBUTE 
::DEFINED.ON 
sTTPB 

:: LEGAL. MEANS 

-. :  IXTERMINATION .  MEANS 

:: PROMPT 

: : TRANSLATION 

END. DEFINE 


opera  tor . ini t iated . shutdown 
inu 

boolean 
(query. user) 

(query. user} 

"Is  this  eessage  the  result  of  an 
operator  initiated  shutdown  ?” 

"the  operator  "  !  verb("initiated", 
"did  not  initiate”)  1  "the  shutdown" 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
::TTPE 

:: LEGAL. MEANS 

: : DETERMINATION. MEANS 

:;PROMPT 

: : TRANSLATION 

END. DEFINE 


pi ck . o f f . signals . good 
inu 

boolean 
(query. user} 

(query. user} 

"Check  the  pick-off  signals.  Are  they  good?  ” 
"the  pick-off  signals  "  I 
verb<"are",  "are  not")  I  "  good" 


DEFINE  ATTRIBUTE 
::DBFINBD.ON 
sTTPB 

:: LEGAL. MEANS 

: : DETERMINATION. MEANS 

::PROMPT 


: : TRANSLATION 


END. DEFINE 


pi ck . of f . signals . whi le . gyros . no t . running . good 
im 

boolean 
(query. user} 

(query. user) 

"Move  the  IMU  to  the  Node  B  station. 

Check  the  pick-off  signals  while 
the  gyros  are  not  running.  Are  they  good?" 
"the  pick-off  signals  "  I  verb("are",  "are 
not")  !  "  good  while  the  gyros  are  not 
running" 


lU 
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I 


MFINB  ATTRIBVrE 
:: DEFINED. ON 
I :TTPB 

: :LBGAL.NBANS 

: : DETERMINATION. MEANS 

::PRONPT 


: : TRANSLATION 
END. DEFINE 


pos  i  t  i  on .  1 1 .  se  1 1  i  ng .  i  s .  no  nal 
iau 

boolean 
(query. user) 

(query. user) 

"Check  aeter  N2  in  the  NCC  (setting  position 
11).  Is  the  reading  noraal  (50Z)?" 

"the  reading  on  neter  N2  position  11  "  ! 
verb("is",  "is  not")  !  "  noraal" 


ISFINE  ATTRIBUTE 
::DEFINED.ON 
::TTFE 

:: LEGAL. MEANS 
: :DETERNINATION. MEANS 
::PROMPT 


: : TRANSLATION 
END.IffiFINE 


posi tion . 21 . set t ing . is . noraal 
iau 

boolean 
(query. user) 

(query. user) 

"Check  aeter  N2  in  the  NCC  (setting  position 
21).  Is  the  reading  noraal  (SOX)?" 

"the  reading  on  aeter  N2  position  21  "  ! 
verb("is",  "is  not")  I  "  noraal" 


DEFINE  ATTRIBUTE 
::DEFINED.ON 
: :TTFE 

:: LEGAL. MEANS 
: :I«TERNINATION. MEANS 
t.'PRONFT 

: :TRAMSLATION 
END. DEFINE 


power . cube . good 
iau 

boolean 
(query. user) 

(query. user) 

"Move  the  INU  to  the  Mode  B  station 
and  check  the  power  cube.  Is  it  good?" 

"the  power  cube  "!verb("is","is  not")!"  good" 


DEFINE  ATTRIBUTE 
::DBFINED.ON 
::TTFE 

: t LEGAL. MEANS 

: : DETERMINATION. MEANS 

::PRONPT 

: : TRANSLATION 

END. DEFINE 


power . was . interrupted 
iau 

boolean 
(query. user) 

(query. user) 

"Vas  power  interrupted?" 

"power  "  I  verb("was",  "was  not")  I  " 
interrupted” 


KFINE  ATTRIBUTE 
::I»FINED.ON 
: ;TTPE 

:: LEGAL. MEANS 

: : DETERMINATION. MEANS 

::raOMPT 


:: TRANSLATION 


END.I«FINE 


precision . curren  t . ne  twork . good 
iau 

boolean 
(query. user) 

(query. user) 

"Check  the  precision  current  network 
test  points  33,  34,  and  36.  Are  the 
signals  good?" 

"the  precision  current  network  "  f  verb("is”, 
"is  not")  I  "good" 
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OBFINB  ATTRIBITTB 
: tDEFINBD.ON 
: iTTPB 

itUBGAL. MEANS 
:  :1«TERNII1ATI0N 
::PROHFT 

: : TRANSLATION 

END. DEFINE 

DEFINE  ATTRIBUTE 
:  :I»FINED.(HI 
; :TTPE 

:: LEGAL. MEANS 
:: DETERMINATION 
: {PROMPT 

: {TRANSLATION 

BND.I»FINE 

DEFINE  ATTRIBUTE 
{{DEFINED. ON 
{ {TYPE 

{{LEGAL. MEANS 

{{DETERMINATION 

{{PROMPT 

{ {TRANSLATION 

END. DEFINE 

l»FINE  ATTRIBUTE 
{{DEFINED. ON 
•TTPB 

:: legal. MEANS 

{{DETERMINATION 

{{PROMPT 


{ .’TRANSLATION 


previ ous . iau . aaj or 
iau 

boolean 
(query. user} 

MEANS  (query. user} 

"Has  an  IMU  Major  Fault  (0504) 
occurred  previously  on  this  IMU?" 

"a  previous  IMU  aajor  fault  "  !  verb("has", 
"has  not")  !  "  occurred  on  this  IMU" 


problea. follows. aap 
ini 

boolean 
(query. user) 

MEANS  (query,  user) 

"Exchange  the  electronic  control  aaps.  Does 
the  problea  follow  the  card?" 

"the  problea"  !  verb(* follows", "does  not 
follow")!  "  the  card" 


problea. follows . giabal . ra te . aap 
iau 

boolean 
(query. user) 

MEANS  (query. user) 

"Exchange  the  giabal  rate  aaps.  Does  the 
problea  follow  the  card?" 

"the  problea"  f  verb(" follows", "does  not 
follow")!  "  the  card" 


problea . follows . board 
iau 

boolean 
(query. user) 

MEANS  (query. user) 

”^e  servo  disable  occurred  because  of  excess 
rate.  Interchange  rate  aaps  AR  12,  13,  and 
14.  Does  the  problea  follow  the  bMrd?" 

"the  problea"  !  verb(" follows", "does  not 
follow")!  "  the  card" 


END. DEFINE 


1 
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DEFINE  ATTRIBUTE 
::DEFINED.ON 
•  vTTPB 

t: LEGAL. MEANS 
: :I»TERHINATION. MEANS 
: : TRANSLATION 
END.DEPINE 


pover . dovn . Bessage 
iau 

boolean 
{try. rules} 

(try. rules) 

"the  Message  is  a  result  of  a  pover  dovn" 


KFINE  ATTRIBUTE 
::DEFINED.ON 
;:TTPE 

:: LEGAL. MEANS 
: :raTERMINATION. MEANS 
•.‘.PROMPT 

: :TRANSLATION 

END.DEPINE 


pover . supply . 4 . Bkhz . good 
inu 

boolean 
(query. user} 

(query. user} 

"Install  the  diagnostic  cap  and  check  test 
point  23.  Is  the  4.8  khz  pover  supply  good?" 
"the  4.8  khz  pover  supply  "  !  verb("is"t 
"is  not")  !  "  good" 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
::TTPE 

:: LEGAL. MEANS 
: :I«TERMINATION. MEANS 
:: PROMPT 

: : TRANSLATION 

END.IKFINE 


pover . supply . 400hz . good 
inu 

boolean 
(query. user} 

(query. user) 

"Check  test  point  13.  Is  the  400  hz  pover 
supply  good?" 

"the  400  hz  pover  supply  "  !  verb("is", 
"is  not")  I  "  good" 


KFINE  ATTRIBUTE 
::DEFINE0.0N 
: :TTPE 

:: LEGAL. MEANS 
:  :I»TERMINATI(Ni. MEANS 
: -.PROMPT 


: :TRANSLATI0N 

END.DEPINE 


problen . f ollovs . pover . supply . card 
inu 

boolean 
(query. user) 

(query. user) 

"Exchange  PSl  and  PS2  (the  pover  supply 
cards).  Does  the  problen  follov  the 
cards?" 

"the  problen  "  I  verb("  follovs",  "does  not 
follov")  !  "  the  pover  supply  cards 
vhen  PSl  and  PS2  are  exchanged" 


L 
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DEFINE  ATTRIBUTE 
::DEFINBO.ON 
::TTPB 

:: LEGAL. MEANS 

: :  KTERHIMATION.  MEANS 

::PRONPT 


:  -.TRANSLATION 


END. DEFINE 


problea. follows . speed . control . card 
im 

boolean 
(query. user) 

(query. user) 

"Exchange  the  two  speed  control  cards. 
Does  the  problea  stay  with  the  saae  card 
(ie.  did  the  problea  change  to  the  other 
direction)?  " 

"the  problM  "  !  verb(" follows",  "does 
not  follow")  I  "  the  speed  control  card 
when  the  cards  are  exchanged" 


DEFINE  ATTRIBUTE 
:tDBFINED.ON 
::TTFE 

:t LEGAL. MEANS 
: : DETERMINATION. MEANS 
: : TRANSLATION 

END. DEFINE 


rare . error . aessage 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  error  aessage  received  is  rarely 
received  during  Mode  A  tests" 


DEFINE  ATTRIBUTE 
::I»FINED.ON 
::TTPE 

:: LEGAL. MEANS 
:  :I»TERNINATION.IffiANS 
: {TRANSLATION 
END. DEFINE 


replace. ar8 
iau 

boolean 
(try. rules) 
(try. rules) 
"replace. arS" 


KFINE  ATTRIBUTE 
: {DEFINED. ON 
{{TYPE 

{{LEGAL. MEANS 
{ {DNTBRNINATION. MEANS 
{ {TRANSLATION 
END. DEFINE 


replace . digi tal . processor 
iau 

boolean 
(try. rules) 

(try. rules) 

"replace  the  digital  processor" 


DEFINE  ATTRIBUTE 
{♦.DEFINED. ON 
{{TYPE 

{ .-LEGAL.  MEANS 
{ {DETERMINATION. MEANS 
{ {TRANSLATION 
END. DEFINE 


replace .faulty. coaponen  t 
iau 

boolean 
(try. rules) 

(try. rules) 

"replace  the  coaponent  deterained  faulty" 
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DBFIIR  ATTRIBUTE 
:: DEFINED. ON 
::TTFB 

: t LEGAL. MEANS 
:  xMTERMINATION.  MEANS 
:  .-TRANSLATION 
replaced* 

BND.IMBFINE 

WFINE  ATTRIBUTE 
.-.-ISPINED.ON 
::TTPE 

:: LEGAL. MEANS 
: :l«TERMINATIOM. MEANS 
: tTRANSLATION 
END. DEFINE 

DEFINE  ATTRIBUTE 
: -.DEFINED. ON 
::TTPE 

:: LEGAL. MEANS 
: : DETERMINATION . MEANS 
:.- PROMPT 

:  -.TRANSLATION 

END. DEFINE 

DEFINE  ATTRIBUTE 
-.:  DEFINED.  ON 
s:TTPE 

:: LEGAL. MEANS 

: : DETERMINATION. MEANS 

::PROMFT 

: : TRANSLATION 

END. DEFINE 

DEFINE  ATTRIBUTE 
: -.DEFINED.  ON 
::TTPE 

:: LEGAL. MEANS 
: :ISTERMINATION. MEANS 
.-:PRONPT 

:  -.TRANSLATION 

END.DEFINB 


replace. platfora. electric. svitch 
ini 

boolean 
(try. rules} 

(try. rules) 

"the  platfora  electric  svitch  should  be 


replace . 4 . 8 . khz . power . supply 
ini 

boolean 
(try. rules) 

(try. rules) 

"replace  the  4.8  khz  power  supply" 


replacing. ar8 . helps 
ini 

boolean 
(query. user) 

(query. user) 

"Replace  AR8  mdule.  Did  that  solve  the 
problm?" 

"replacing  AR8  "  I verb( "solved",  "did  not 
solve")  I  *  the  problea" 


replacing . power . supply . solved . problen 
ini 

boolean 
(query. user) 

(query. user) 

"Replace  the  4.8  khz  power  supply  (PSIO).  Did 
that  repair  the  INU?" 

"replacing  the  4.8  khz  power  supply  "  I 
verb(*repaired","did  not  repair"}!"  the  INU" 


resolver . exci tat ion . good 
ini 

boolean 
(query. user) 

(query. user) 

"Check  tiM  excitation  signal  to  the 
resolver.  Is  it  good?" 

"the  excitation  signal  to  the  resolver  * 
!  verb<"is",  "is  not")  !  "  good" 
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DBFIMB  ATTRIBUTE 
:  :IXPIIIBD.ON 
:iTIPB 

::  LEGAL.  MEANS 

: : DETERMINATION. MEANS 

::PRONPT 


: : TRANSLATION 

END.I»FINE 

DEFINE  ATTRIBUTE 
riMFINED.ON 
: :TTFE 

:: LEGAL. MEANS 

: : DETERMINATION. MEANS 

::PRONPT 

: : TRANSLATION 

END. DEFINE 


DEFINE  ATTRIBUTE 

::DEFINED.ON 

::TTPE 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
:: PROMPT 
t  sTRjMISLATION 
END.DEFINE 


resolver . signal . on . di fferen t . s tat ion . good 
iau 

boolean 
(query. user) 

(query. user) 

"Move  the  IMU  to  another  station.  Recheck  the 
excitation  to  the  resolver.  Is  the  signal 
good?" 

"the  resolver  signal  "  !  verb("is",  "is  not") 
I  "  good  at  another  test  station" 


resolver . output . at . ncc . good 
iau 

boolean 
(query. user) 

(query. user) 

"Check  the  resolver  signal  output  at 
the  NCC.  Is  the  signal  good?" 

"the  resolver  signal  output  at  the  NCC  "  ! 
verb("ia",  "is  not")  I  "  good" 


r es tar t . poss ible 
iau 

boolean 
(query. user) 

(query. user) 

"Atteapt  a  restart.  Is  a  restart  possible?" 
"a  restart  "Iverb("ls","is  not")I"  possible" 


DEFINE  ATTRIBUTE 
:;1»FINBD.0N 
; :TTPE 

t: LEGAL. MEANS 
: :DBTERMIMATIOM. MEANS 
: :TRANSLATION 
END.DEFINE 


return. to. test 
iau 

boolean 
(try. rules) 

(try. rules) 

"return  to  test  after  Installing  the  cap" 


DEFINE  ATTRIBUTE 
: :DEFINED.ON 
::TTPE 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: : TRANSLATION 
END.DEFINE 


run. next. test 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  next  test  "!verb("was","was  not")!"  run" 
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DBPIMB  ATTRIBVTE 
:: DEFINED. ON 
sXTPB 

:: LEGAL. KEANS 
:  :l«TBIUfINATION.  KEANS 
: :TRANSLAT10N 
BND.WFINB 


run.scorsby. test 
iau 

boolean 
(try. rules} 

(try. rules} 

"run  the  scorsby  test  on  the  IKU  " 


DEFINE  ATTRIBITTE 
::DBFINBD.ON 
: jTTPE 

:: LEGAL. KEANS 

: : DETERMINATION. KEANS 

f.PROKPT 


: : TRANSLATION 
END. DEFINE 


scorsby. good 
inu 

boolean 
(query. user} 

(query. user} 

"Put  the  IKU  on  the  Scorsby  table. 
Does  it  pass  the  Scorsby  test?” 

”the  IKU  ”  !  verb( "passed”,  ”did  not 
pass”)  !  ”  the  Scorsby  test” 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
:  :TTPE 

:: LEGAL. KEANS 
: :1»TBRNINAT10N. MEANS 
: : TRANSLATION 

END. DEFINE 


see . shop. supervisor 
iau 

boolean 
(try. rules) 

(try. rules) 

"contact  the  shop  supervisor  for  assistance 
in  troubleshooting  the  fault." 


DEFINE  ATTRIBUTE 
::DBFINED.ON 
s:TTPE 

:: LEGAL. KEANS 
: : DETERMINATION. MEANS 
:: PROMPT 

t iTRANSLATION 

END.ISFINE 


speed . control . for . blA . and . up . good 
iau 

boolean 
(query. user} 

(query. user} 

"Monitor  the  speed  control  for  B-14 
and  above.  Are  the  values  good?” 

”the  speed  control  values  for  B14  and  above  ” 
!  verb("are”,  "are  not”)  !  ”  good” 


DEFINE  ATTRIBUTE 
;:l»FINED.OH 
: :TTPE 

:: LEGAL. MEANS 

: : DETERMINATION . MEANS 

.'.•PROMPT 

: sTRANSLATION 

END. DEFINE 


speed . control . signal . good 
iau 

boolean 
(query. user) 

(query. user} 

"Check  the  speed  control  signals  vith  the 
IKU  cap  on.  Are  the  signals  good?" 

”the  speed  control  signals  ”  I 
verb("are”,  "are  not”)  I  "  good” 
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MPIMB  ATTRIBUTE 
t:l»PlliED.OW 
«TTPB 

:: LEGAL. VALUES 
: -.LEGAL.  MEANS 
:  :ISTERNINATION.  MEANS 
: : TRANSLATION 
END.MFINE 


suspect. va 

iau 

text 

(velocity.aeter.x,  velocity. aeter.y) 
(try. rules) 

(try. rules) 

”the  suspected  velocity  Beter” 


DEFINE  ATTRIBUTE 
::ISFINED.ON 
::TTPE 

:: LEGAL. MEANS 

: : DETERMINATION. MEANS 

::PRONFT 

: : TRANSLATION 

END. DEFINE 


svi  tch . solves . problea 
iau 

boolean 
(query. user) 

(query. user) 

"Replace  the  platfora  electric  svi tch  (A7). 
Does  that  solve  the  problea?" 

"replacing  the  platfora  electric  switch  "  I 
verb("did",  "did  not")  1  "  solve  the  problea" 


DEFINE  ATTRIBUTE 
::DEFINBD.ON 
: :TTPE 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
t: PROMPT 

:  -.TRANSLATION 

END. DEFINE 


sys  tea. achieved . gyro . noraal 
iau 

boolean 
(query. user) 

(query. user) 

"Bas  the  systea  achieved  gyro  noraal  during 
this  test?" 

"the  systea  "  !  verb("has",  "has  not")  ! 
"achieved  gyro  noraal  during  this  test” 


DEFINE  ATTRIBUTE 
: vDEFINED.ON 
: :TTPE 

.-:  LEGAL.  VALUES 


:: LEGAL. MEANS 

: : DETERMINATION. MEANS 

::FRONPT 

: : TRANSLATION 
END.DEFINE 


test 

iau 

text 

(shia.cal,  gyro. cal,  self. align, 
nav. align,  navigate) 

(query. user) 

(query. user) 

"Vhat  test  was  the  station  in  when 
the  fault  occurred?" 

"the  current  test" 
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dbphib  ATTRiBinrs 

ttDBFlMBD.OH 

::TTPB 

:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: :TRANSLATION 

BND.IKFINE 


use.accoapanying.aessages. to. troubleshoot 

iMl 

boolean 
{try. rules) 

(try. rules) 

"use  accoapanying  aessages  to  troubleshoot 
the  problea” 


DEFINE  ATTRIBUTE 
::DEFINED.ON 
• sXTPB 

:: LEGAL. MEANS 

: :  WTERNINATION. MEANS 

::PROMPT 


:  .'TRANSLATION 
END. DEFINE 


velocities. changed . d i rec  t i ons 
iau 

boolean 
(query. user) 

(query. user) 

"Continue  the  cal  and  wait  for  the  platfom 
to  slev.  Did  the  velocities  change 
direction?  " 

"the  velocities  changed  directions 
vhen  the  plat fora  sieved" 


DEFINE  ATTRIBUTE 
:  .'DEFINED. ON 
: :TTPE 

:: LEGAL. MEANS 
t : DETERMINATION.  KEANS 
: : TRANSLATION 
BND.DBFINE 


velocity.aeter. is. suspect 
iau 

boolean 
(try. rules) 

(try. rules) 

"the  velocity  aeters  are  suspected" 


DEFINE  ATTRIBUTE 
: '.DEFINED.  ON 
: :TTPE 

:: LEGAL. MEANS 
: .'  DETERMINATION .  MEANS 
:: PROMPT 


: :TRANSLATION 
END. DEFINE 


veloci ty . on . ncc . is . zero 
iau 

boolean 
(query. user) 

(query. user) 

"Check  the  velocity  of  the  velocity  aeter  on 
the  NCC.  Is  the  velocity  zero?" 

"the  velocity  of  the  velocity  aeter  is  zero" 


KFINE  ATTRIBUTE 
::I»FINED.ON 
:  :TTPE 

:: LEGAL. MEANS 
: tlffiTERNINATION. MEANS 
:: PROMPT 

:: TRANSLATION 

END. DEFINE 


va. s ignal . on . ncc . good 
iau 

boolean 
(query. user) 

(query. user) 

"Check  the  velocity  aeter  signal 
on  the  NCC.  Is  it  good?" 

"the  velocity  aeter  signal  "  !  verb("is",  "is 
not")  !  "good  on  the  NCC" 
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IMBFINE  ATTRIBirrS 
::DBPINBO.ON 
: :TT?B 

:: LEGAL. MEANS 
:: DETERMINATION. MEANS 
: : TRANSLATION 
aiD. DEFINE 


wait. for. plat fora. to. slew 
lau 

boolean 
{try. rules) 

{try. rules) 

"vait  for  the  platfora  to  slew" 


I«FINE  ATTRIBUTE 
::ISFINED.ON 
: :TTPE 

:: LEGAL. MEANS 

: : DETERMINATION. MEANS 

;:PROMPT 

t : TRANSLATION 


END. DEFINE 


yz . f aul t . occurred . aore . than . twice 
iau 

boolean 
(query. user) 

(query. user) 

"Has  the  TZ  gyro  speed  control  fault 
occurred  aore  than  twice?” 

”the  TZ  gyro  speed  control  fault  ”  1 
verb(”has",  "has  not")  I  "  occurred 
aore  than  twice” 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
; :TTPE 

:: LEGAL. MEANS 
: : DETERMINATION . MEANS 
:: PROMPT 

: : TRANSLATION 


yz. speed. control. stable 
iau 

boolean 
(query. user) 

(query. user) 

"Move  the  IMU  to  the  Mode  B  station. 
Is  the  TZ  speed  control  stable?” 
"the  TZ  speed  control  ” 

!  verb("is”,  "is  not")  !  "  stable" 


END. DEFINE 


Z***********************************************************************/ 


/*  */ 

/*  VALUE  HIERARCHIES  */ 

/*  */ 

/*  These  are  value  hierarchy  definitions  */ 

/*  Error  Messages  list  all  62  possible  error  aessages  that  can  be  */ 

/*  generated  by  the  DNINS  Autoaatic  Test  Bquipaent.  */ 


DEFINE  VALUE. HIERARCHY  error . aessages 
: : SUBVALUES  { veloc i ty . unreasonable , 

vt. greater. than. 2. knots, 

xy . speed . con t rol , 

yz . speed . control , 

iau.aajor, 

no . input . 3 . axes , 

no. input. az, 

no. input. pitch, 

no. input. roll, 

autoaatic. shutdown, 

iau.o.load, 

iau.o.teap, 

pvr. interrupt, 

dec. o. load. o. teap, 

dcc.o.teap, 

i.c. fault, 

coap. tie. in. sv. on, 

i . c . f aul t . inhb . enab , 

seq . cn t . no . coapar e , 

i . c . da ta . loop . f aul t , 

i.c. fault. cont, 

in. parity. test. inhb. enab, 

ou t . word . par . inhb . enab , 

input . pari ty . f aul t , 

output .word . pari ty . f aul t , 

output . word . pari ty. cont , 

excess. angle, 

servo. disable, 

aa j or . rese t . f aul t , 

z.stab, 

systea.  in.  free.nui, 

ainor . rese  t . f aul t , 

ainor . f aul t . cont , 

iau. ainor, 

plat . s tab . abor t , 

xva. precounter . fault , 

yva. precounter . f aul t , 

both . va . precounter . fai lure , 

va . bi te . f ai lure , 

x. gyro. torque. fault, 

y. gyro. torque. fault, 

z. gyro. torque. fault, 
systea. not . properly . caged , 
gyro. hot. 


i 


gyro. cold, 
gyro. teap.noraal, 

■ux . decoder . dl . faul t , 

cage . xy . dl . f aul t , 

cage . yz . dl . faul t , 

gy ro . s tar t . dl . faul t , 

gy ro . run . dl . faul t , 

uyk . good . dl . faul t , 

inpu t . par i ty . dl . faul t . auxOA , 

input.parity.no.2.dl. fault, 

ou t pu t . word . par i ty . dl . faul t . ■ux09 , 

vt . vr . grea ter . than . 3 . knots , 

■inis ins . vel . d i f . exceeds . liai t , 
■inisins . pos . di f . exceeds. liai t , 
parity. test. 1. no. go, 
parity. test. 2. no. go, 
parity. test. 3. no. go, 
pu t . in ter coa . t es t . no . go , 
ras. out. of .spec] 

: :TRANSLATION  "  error  aessages  " 

::VALUE  "  error. aessages  " 

END. DEFINE 


/*  Possible  Faults  include  the  38  Shop  Replaceable  Units  (SRU)  in  a  */ 
/*  DMINS  IMU  as  veil  as  coaaon  terns  for  groups  of  conponents  (such  as  */ 
/*  "speed  cards")  often  used  by  DKINS  technicians.  *! 


DEFINE  VALUE. HIERARCHT  possible. faults 
:;SUBVALUBS  (bandpass. f liter. and. shift. register. 1, 

bandpass . f i 1 ter . and . shi f t . regi s t er . 2 , 
precision. torquing. driver. x, 
precision. torquing. driver. y, 
precision. torquing. driver. z, 
plat  fora . elec  t  r on i c . svi  tch , 
shor t ing . plug , 
precision. current. netvork, 
s table . plat fora , 
d isplaceaen  t . gyroscope . xy , 
d isplaceaen  t . gyroscope . yz , 
velocity. aeter.x, 
veloci ty . aeter . y , 
resolver .buffer. aap , 
gyro . buf f er . anp . xy , 
gy ro . buf f er . aap . yz , 
xy . 640hz . power . supply , 
yz.640hz. power. supply, 
power. cube, 

no . 1 . 400hz . power . supply , 
no .  2 . 4()0hz .  power .  supply , 

triangle . generator . and . case .rotation. power . supply , 
power . supply . 4 . 8khz , 
frequency . s  tandard , 
d.c.anplifier.xy. 
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: : TRANSLATION 
:: VALUE 
END. DEFINE 


d.c.aaplifier.yz, 

synchro . s ignal . bu f fer . aap , 

gyro. cage. aap, 

theraoelectric. signal .aapt 

gyro . tenpera ture . controller , 

ginbal . cage . aap , 

plat fora. signal. aap, 

pla t fora . elec t ron i c . con t rol . aap . rol 1 , 

plat fora. electronic . control. aap .pitch, 

pla t fora . elec t ron i c . con t rol . aap . az iau th , 

gl abal . ra te . elec t roni c . con t rol . aap . roll , 

giabal . rate . elec t ronic . con t rol . aap . pi t ch , 

giabal . rate . electronic . control . aap . aziau th , 

corresponding. giabal .rate. elec  t  ron i c . con  t  rol . aap , 

cor respond i ng . giabal . ra te . aap , 

corresponding . electronic. control . aap , 

platf ora. electric. switch, 

corresponding . gy ro , 

gyro, 

corresponding. veloci ty.aeter, 
speed. card, 

corresponding. speed. card , 
power . supply . card , 
corresponding . power . supply . card , 
resolver , 

exci ta t ion . aodule , 
bad. cable, 
none, 

no t . de terai ned ) 

”  possible  faults  ” 

"possible. faults" 
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/*  */ 

/*  RULBS  */ 

/*  */ 

/*  Rules  in  this  progran  are  in  groups  according  to  the  error  */ 

/*  aessage  they  are  atteepting  to  troubleshoot.  This  is  done  to  */ 

/*  increase  the  aaintainabillty  of  the  prograa.  */ 

/*  */ 

/*  The  first  group  of  rules  define  actions  that  are  concluded  */ 

/*  throughout  the  prograa.  They  are  placed  at  the  beginning  of  the  */ 

/*  prograa  to  increase  readability.  */ 

/*  */ 

/*  The  attribute  "action"  is  used  to  pass  recoasiendations  to  the  user.  */ 
/*  "Fault"  is  detemined  so  that  S.l  can  be  queried  for  faults  of  */ 

/*  previous  sessions  using  the  "vfaat"  coaaand.  If  no  fault  can  be  */ 

/*  deterained,  fault  defaults  to  not.deterained.  */ 


KFINE  RULE  ruleOOl 
::APPLIBD.TO  I:IMU 

::PREMISE  not. indication. of .fault{I] 

t: CONCLUSION  begin 

action[I]  =  "continue  testing.  This  error  aessage  is 
not  an  indication  of  a  fault  in  the  INU"; 
fault{l]  E  none; 
end 

END. DEFINE 

DEFINE  RULE  rule002 
::APPLIED.TO  I:INU 
::PRENISE  pover.dovn.nessage(I{ 

:: CONCLUSION  begin 

action[I]  =  "This  error  aessage  is  not  an  indication  of 

an  INU  fault.  Usually »  it  is  associated  vith 
a  poverdovn.  If  this  is  not  the  case, 
contact  T.E.  to  inspect  the  test  equipaent"; 
fault(I]  -  none; 
end 

END. DEFINE 

DEFINE  RULE  rule003 
::APPUED.TO  I:  INU 

: rPREHISE  use.accoapanying.aessages. to. troubleshoot  II) 

::CONCLUSION  action(I)  «  "This  error  aessage  is  noraally  seen  vith  other 

aessages.  It  does  not  contribute  any  useful 
infomation.  Use  the  error  aessages  that 
accoapany  this  aessage  for  troubleshooting” 

END. DEFINE 

DEFINE  RULE  ruleOOA 
::APFLIBD.TO  I: INU 

t:PRBHISE  replace. faulty. coaponentfl) 

::CONCLUSION  actionll]  >  "Recoaaend  that  the  ”!fault(I]  I  "  be  replaced" 
BND.DBFINE 


DBFINB  RULE  ruleOOS 
::APPLIBD.TO  I:IMU 
::FltBNISB  contact.  te(I] 

:  :COIiCUfSION  begin 

action{I]  >  "Call  T.B.  to  check  the  test  equipnent.  There 
is  reason  to  believe  the  test  equipment  is  at  fault”; 
fault(II  none; 
end 

BHD. DBFINB 

DBFINB  RULB  nile006 
::APPUBD.TO  I:INU 
::PRBNISB  see. shop. supervisor! I] 

::CONCLUSION  action[I]«”this  is  a  difficult  problen  to  troubleshoot. 

Contact  the  shop  supervisor  for  further  assistance.  Once 
the  fault  has  been  detenined,  contact  the  engineering 
section  so  this  prograa  can  be  updated  to  include  the  nev 
inforaation” 

END. DEFINE 

DBFINB  RULB  ruleOO? 

::APPLIED.TO  I:IMU 
::PRBNISB  aove. to.Bode.b[I] 

::CONCLUSION  action(I]  s”Move  the  IHU  to  Node  B  for  further  diagnostics” 

END.raFINB 


DBFINB  RULB  nileOOS 
::APPLIBD.TO  I:IMU 

: :PREHISE  fault. found. continue. Cesting{I] 

t {CONCLUSION  action(I]  "Continue  testing.  The  fault  vas  in  the  ” 

fault (II 

BND. DBFINB 


DBFINB  RULE  rule009 
::APPLIBD.TO  I: IHU 
::PRBNISB  rare.error.aessagell] 

: {CONCLUSION  action(I]  >  "This  error  aessage  is  not  coaaon  during  Mode  A 

tests.  Contact  the  shop  supervisor  for  further 
assistance.  Once  the  fault  has  been 
deterainedf  contact  the  engineering  section  so 
this  prograa  can  be  updated  to  include  the  nev 
inforaation” 


END.DBFINB 


/*  This  group  of  rules  check  the  error  aessage  to  deteraine  if  there  */ 
/*  is  an  actual  fault  in  the  INU  or  if  the  error  aessage  vas  due  to  a  */ 
/*  routine  action.  This  group  includes  rules  009  -  012  and  corresponds  */ 
/*  to  the  following  error  aessages:  */ 
/*  input. parity. fault,  */ 
/*  output. word. parity. fault,  */ 
/*  output. word. parity. cont,  */ 
/*  gyro.teap.noraal,  */ 
f*  aux. decoder. dl. fault,  */ 
/*  cage. xy.dl. fault,  */ 
/*  cage. yz.dl. fault,  V 
/*  gyro. start. dl. fault,  */ 
/*  gyro. run. dl. fault,  */ 
/*  uyk. good. dl. fault,  */ 
/*  input. pari ty.dl.fault.auxOA,  */ 
/*  input. parity. no. 2. dl. fault,  */ 
/*  output. word. parity. dl. fault. nux09,  */ 
/*  iau.ainor.  */ 


DEFINE  RULE  ruleOlO 

:: APPLIED. TO  I:IMU 

::PRENISB  error.aessage(I]  is  in  (input. parity. fault, 

output. word. parity. fault, 
ou t put . word . par i ty . con t , 
gyro.teap.noraal) 

; : CONCLUSION  no t . indicat ion . of . f aul t ( I ] 

END. DEFINE 

DEFINE  RULE  ruleOll 

:: APPLIED. TO  I:INU 

::PREMISE  error.nessage[I]  is  in{nux. decoder. dl. fault, 

cage. xy.dl. fault, 

cage . yz . dl . f aul t , 

gy ro . s tar t . dl . f aul t , 

gyro . run . dl . f aul t , 

uyk. good. dl. fault , 

input . par i ty . dl . f aul t . auxOA , 

input.parity.no.2.dl. fault, 

output . word . par i ty . dl . f aul t . nux09 } 

::C0NCLUSI0N  power. down. aessage( I] 

BND.IKFINE 

DEFINE  RULE  rule012 

::APPLIED.T0  I:IHU 

::PREMISE  error.aessage(I]  is  iau.ainor 

: : CONCLUSION  use . accoapany i ng . aessages . to . t  roubleshoo  t [ I ] 

END.ISFINE 


/*  Rule  013  includes  all  of  the  rare  error 
DEFINE  RULE  rule013 
::APPLIED.T0  1:INU 
::PREIfISE  error.aessage[I]  is  in 


essages . 


*/ 


:: CONCLUSION 
END. DEFINE 


rare . error. ■essage[ I ) 


(inu.o.load, 
inu.o.teap, 
dec. o. load. o. tenp, 
dcc.o. tenp, 
coap. tie.in.sv.on, 
i.c. fault. inhb.enab, 
i.c. data. loop. faulty 
i.c. fault. cont, 
in. parity. test. inhb.enab, 
ou t . word . par . i nhb . enab , 
output. word. parity. cont, 

■ajor. reset . fault , 

■inor. reset . fault , 

■inor. fault . cont , 

bo th . va . precoun  ter . failure , 

va . bi te . f ai lure , 

vt.vr.gr eater. than. 3. knots, 

ainisins . vel . di f . exceeds . liai t , 

ainisins . pos . di f . exceeds .liai t , 

parity. test. 1. no. go, 

parity. test. 2. no. go, 

parity. test. 3. no. go, 

put . intercoa. test . no . go , 

seq . cn t . no . coapar e } 


/*♦**************★******♦*******************************♦*******♦*******/ 


/*  This  group  of  rules  includes  rules 

014  -  022  and  diagnoses  the 

*/ 

!*  following  four  error  aessages: 

*/ 

/* 

no. input . 3 . axes , 

*/ 

/* 

no. input. az. 

*/ 

/* 

no. input. pitch. 

*/ 

/* 

no. input. roll. 

*/ 

KFINB  RULE  rule014 
:tAPPLIED.T0  I:IHU 

:tPREHISB  error.aessagefl]  is  in  (no. input. 3. axes, 

no. input. az, 
no. input. pitch, 
no. input. roll} 

: :C0NCLUSI0N  check. resolver. signal. at. ncc|I] 

END. DEFINE 

I»PINB  RULE  ruleOlS 
::APPLIED.T0  I:INU 

::PREMISB  check. resolver. signal. at. ncc(I)  and 

resolver . ou t pu t . a t . ncc . good { I ) 
::C0NCLUSI0N  contact. te(I] 

BND.DBFINB 
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DEFINE  RULE  rule016 
::APPLIEO.TO  I:INU 

t:PRBHISB  check. resol ver.slgnal.at.nccl I]  and 

not  resolver. output. at. ncc.good(I] 

: tCONCUlSION  check. resolver. signal. at. 

END.DBFINB 

1»FINB  RULE  ruleOl? 

::APPLIED.TO  I:INU 

::PRENISE  check. resolver. signal. at. inull]  and 

inu . resolver . s ignal . good I I ] 

: :CONCLUSION  check. resolver. signal. on. dif£erent.station[I] 
END.DBFINB 

DEFINE  RULE  ruleOlS 
::APPLIED.TO  I:INU 

::PRBMISE  check. resolver. signal. at. iauf I]  and 

not  inu. resolver. s ignal. goodj I] 

: :CONCLUSION  check. resolver. excitation[ I] 

END.DBFINB 

ISFINB  RULE  rule019 
::APPLIED.TO  I:IMU 

::PRBHISE  check. resolver. signal. on. di££erent.station[ I]  and 

resolver . signal . on . di ££erent . s tat ion . good I I ] 
::CONCLUSION  contact. te(I] 

BND.IffiFINB 

DEFINE  RULE  rule020 
::APPLIBD.TO  I:IMU 

::PREHISE  check. resolver. signal. on. di££erent.station(I]  and 

not  resolver. signal. on. di££erent. station. good( I] 

: : CONCLUSION  check. resolver. excitation! I] 

END.DBFINB 


ISFINB  RULE  rule021 


: :APPLIED.TO 
:: PREMISE 

: : CONCLUSION 


END.DBFINB 


I:INU 

check. resolver. excitationll]  and 
resol ver . exc i ta t i on . good I I 1 
begin 

replace. £aul ty . conponent I I 1 ; 
£ault(I]  s  resolver; 
end 


I 
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DBPIIIB  RULE  rule022 
::APPLIBD.TO  I:IMU 

::PRBNISE  check. resolver. excitation|I]  and 
not  resolver. excitation. good(I] 

:: CONCLUSION  begin 

replace . faul ty . coaponen  t { I ) ; 
fault [I]  s  excitation. nodule; 
end 

END. DEFINE 

/***1rk***1rk1t*********1tk****ti  *****************★********************/ 

/*  ***  Rules  for  Transition  *** 

*/ 

/*  Transition  froa  shallow  to  deep  reasoning  occurs  in  Rules  24,25,35,  */ 


/*  36,38,  and  41.  Rules  26,27,28,29,39,40,  and  42  were  eliainated  */ 
/*  by  coaaenting  then  out.  The  eliainated  rules  were  left  in  place  to  */ 
/*  provide  an  exaaple  of  the  procedure  for  future  additions  to  the  */ 
/*  prograa.  */ 
/*  */ 
/*  Rules  023  -  029  deteraines  the  cause  of  the  following  aessages:  */ 
/*  xy. speed. control,  */ 
/*  yz. speed. control.  */ 


DEFINE  RULE  rule023 
::APPLIED.T0  I:INU 

::PRENISE  error. aessage[ II  is  yz. speed. control  and 
not  yz. f ault. occurred. aore. than. twicefl] 

::  CONCLUSION  begin 

action(I]  «  "No  action  is  required.  If  the  TZ  speed 

control  error  has  not  occurred  note  than 
twice,  it  is  nomally  not  a  problen”; 
fault(I]  =  none; 
end 

END. DEFINE 

DEFINE  RULE  rule024 
t:APPLIED.T0  I.'INU 

::PRENISE  error.nessage{I]  is  xy. speed. control 
::C0NCLUSI0N  action[I]  =  "Begin  deep  diagnosis” 

END.IKFINE 

DEFINE  RULE  rule025 
::APPLIED.T0  I:INU 

::PRENISE  error.nessage[I]  is  yz. speed. control  and 

yz . faul t . occurred . aore . than . twi ce I 1 ] 

::C0NCLUSI0N  actionll]  »  "Begin  deep  diagnosis" 

END. DEFINE 


( 
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/**********************  ELIHINATED  »*»*************»*****»★*****★*»**★*** 
Rules  26,  27,  28,  and  29  were  ellninated  and  replaced  by  eodel  diagnosis 


WFINB  RULE  rule026 
::APPUED.TO  I:INU 

::PRENISE  check. speed. control. signalll]  and 

speed . con t rol . s i gnal . good ( I ] 

::CONCLUSION  action[I]  "Check  the  discretes  on  the  nodules. 

nodule  problen  is  suspected" 


END. DEFINE 


A 


DEFINE  RULE  rule027 
::AFFLIED.TO  I:IMU 

::FRBHISE  check. speed. con t rol. signal{ I]  and 

not  spe^. control. signal. good(I] 

: tCONCLUSION  exchange. speed. control. cardsfl] 
END. DEFINE 


DEFINE  RULE  rule028 
::AFPLIED.TO  I:INU 

::PREHISB  exchange.speed.control.cards[I]  and 

not  problen. f ollovs . speed . control . card [ I ] 
:: CONCLUSION  begin 

replace . faul ty . conponen t I I ) ; 

£ault(l]  ai  corresponding. gyro; 
end 

END. DEFINE 


DEFINE  RULE  nile029 
::APPLIED.TO  I:IHU 

::PRENISE  exchange. speed. control. cardsfl]  and 

problen . follows . speed . control . card [ I ] 

: tCONCLUSION  begin 

replace . faul ty . conponen t I I ] ; 
faultll]  «  corresponding. speed. card; 
end 

END.I»FINE 


I 
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/*  This  group  of  rules  includes  rules  030  -  042  and  troubleshoots  the  */ 


t*  following  tvo  error  messages:  */ 
/*  velocity. unreasonable,  */ 
/*  vt. greater. than. 2. knots.  */ 
/*  In  addition,  this  section  uses  the  routine  Check  Gyro  Circuit,  which  */ 
/*  starts  with  rule  043.  */ 


DBFINB  RULE  rule030 
::APPUED.T0  I:IMU 

::PRBMISE  error.nessage(Il  is  in  {velocity. unreasonable, 

vt. greater. than. 2. knots)  and 

test [I]  is  gyro. cal 
::C0IICLUSI0N  check.positionfl) 

Sm.DBFINE 

DEFINE  RULE  rule031 
::APPLIED.T0  I:IKU 

::PREMISE  error.aessage[I]  is  in  (velocity. unreasonable, 

vt. greater. than. 2. knots)  and 

test [I]  is  navigate 

: :C0NCLUSI0N  check. velocity.direction(l) 

END. DEFINE 

DEFINE  RULE  rule032 
::APPLIED.T0  I:IHU 

::PRENISE  error.aessage(I)  is  in  {velocity. unreasonable, 

vt. greater. than. 2. knots)  and 
not  test[I]  is  in  {gyro. cal,  navigate) 

::C0NCLUSI0N  action{I]«<  "See  the  shop  supervisor.  Norually  this  nessage 

occurs  only  when  the  INU  is  in  gyro. cal  or 
navigate” 

END. DEFINE 

DEFINE  RULE  rule033 
::APPLIED.T0  I:INU 
::PREHISB  check. position! I]  and 

nor th . south . or . eas t . vest I I ] 

: :C0NCLUSI0N  wait.for.platforu. to.slev(I] 

BND.DBFINE 

MFINB  RULE  rule034 
::APPLIED.T0  I: INU 

::PRENISE  vait.for.platfora.to.slev(I]  and 

veloci ties . changed .directions! I ) 

:  .'CONCLUSION  begin 

replace . f aul ty . coaponen t ! I ) ; 
fault!I]  -  corresponding. veloci ty.neter; 
end 

BND.DBFINE 
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{  DBPINB  EULB  rule03S 

::APPUBD.TO  I:IHU 

^  ::PRBltISB  vait.for.platfon.to.slevil]  and 

■  not  velocities. changed. directions[I] 

n  ::OONCLUSION  actionfl]  s*Begin  deep  diagnosis” 

END.KPIIIE 

1  WFINE  EULB  njle036 

'  ::APPLIBO.TO  I:INU 

^  ::PEBMISB  check. position! I]  and 

n  not  north. south. or. east. vestll] 

t :COIiCLUSION  actionfl]  *  "Begin  deep  diagnosis” 

BHD. DEFINE 

DEFINE  EULB  rule037 
::APPUED.TO  I:INU 

::PEENISE  check. velocity. direction(I|  and 

north. south. or. east. vest [I] 

::CONCLUSION  begin 

replace. faulty.coaponentll] ; 

£ault|I]  s  correspondiI^t.veiocity.Beter; 
g  end 

END. DEFINE 

DEFINE  EULB  rule038 
::APPLIED.TO  I:INU 

::PEBMISB  check. velocity. directionfll  and 

^  not  north. south. or. east. vestfl) 

I  ::CONCLUSION  action(I]  «  "Begin  deep  diagnosis” 

BND.DBFINE 

/********** * **************  eliminated  ********************************** 

Eules  39  and  AO  vere  eliminated  and  replaced  by  aodel  based  diagnosis. 

■  DEFINE  EULB  rule039 

::APPUBD.TO  I:INU 

::PEEMISE  check. for. level. plat £ora( I]  and 

not  aziauth. equal. zeroll) 

::CONCLUSION  check. velocity.aeterll) 

BND.DBFINE 

DEFINE  BULB  ruleOAO 
::APPLIED.TO  I:INU 

::PEBMISB  check. velocity.aeter[I|  and 

faul ty . veloci ty . ae ter ! I ) 

::CONCLUSION  begin 

^  replace. faulty. coaponent[Il; 

fault(II  corresponding. velocity.aeter; 

end 

END. DEFINE 

******************»»*»>»*******»**************************************  **/ 
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DBPmB  RULE  rule041 
::APPLIBO.TO  I:INU 

cPRBMISE  check. for. level. platfora(I)  and 

aziauth. equal . zero! I I 

:: CONCLUSION  action{I]  >  "Begin  deep  diagnosis” 

BND.DBPniB 

/************************  piJMTWATBn************************************** 
Rule  42  vas  eliainated  and  replaced  by  aodel  based  diagnosis. 

1»FIIIB  RULE  rule042 
::APPLIBD.TO  I:IMU 

:: PREMISE  check. velocity.aeter[Il  and 

not  faulty. velocity.aeter [I] 

::CONCLUSION  check. gyro. circuit[I] 

BND.DEFINE 

A*********************************************************************  **/ 
/************************************************************************/ 


/*  */ 
/*  CHECK  GYRO  CIRCUIT  ROUTINE  */ 

/*  This  routine  is  used  for  several  different  error  aessages  including  */ 
/*  velocity  unreasonable,  vt.  greater  than  2  knots,  iau  aajor,  and  */ 

/*  plat  stab  abort.  Note:  This  routine  is  no  longer  used  for  velocity  */ 

/*  unreasonable  or  vt  greater  than  2  knots.  The  deep  reasoning  portion  */ 
/*  of  the  prograa  nov  provides  the  logic  for  these  aessages.  */ 


DEFINE  RULE  rule043 
•.tAPPUED.TO  I’.IHU 

::PRENISE  check. gyro. circuit[I|  and 

speed . control . signal . good( I ] 

::CONCLUSION  check. gyro. run. voltage[ I) 

END. DEFINE 

DEFINE  RULE  rule044 
::APPLIED.TO  I:INU 

::PREMISE  check. gyro. run. voltagefi]  and 

gy ro .  run .  vol  tage .  good  1 1 1 
::CONCLUSION  check. pick. off .signals|I] 

END. DEFINE 

DEFINE  RULE  rule045 
::APPLIED.TO  I:IMU 

::PREHISE  check. pick. off .signals(I|  and 

pick. of f . signals . good! I I 

: tCONCLUSION  check. pick. off .signals. while. gyros. not. runningfl] 
END. DEFINE 


WFINE  RULE  rule046 
::APPLIBD.TO  I:INU 

::PREMISE  check. pick. off. signals{Il  and 

not  pick. off .signals. good{I) 

:: CONCLUSION  begin 

replace. faulty . coaponent [ I ] ; 
faultll]  cor  responding,  gyro; 

end 

END. DEFINE 

DEFINE  RULE  rule047 
::APPLIED.TO  I:IMU 

::PRBNISE  check. pick. off .signals. while. gyros. not. running[I]  and 

not  pick.off .signals. vhile.gyros. not. running.goodl I] 
:: CONCLUSION  begin 

replace . f aul ty . coaponent [ I ] ; 
fault (II  s  corresponding. gyro; 
end 

END. DEFINE 

DEFINE  RULE  rule048 
:: APPLIED. TO  I:IMU 

::PRENISE  check. pick. off .signals. while. gyros. not. runningll)  and 

pick.off .signals. while. gyros. not. running. good! I] 

! :CONCLUSION  aonitor. speed. control. for. bl4. and. up[I] 

END. DEFINE 

DEFINE  RULE  ruleOA9 
::APPUED.TO  I:IMU 

::PREMISB  aoni tor. speed. control. for. bl4. and. up(II  and 
speed . con t rol . f or . bl4 . and . up . good [ I ] 

: :C(MICLUSION  run. next. test[I] 

END. DEFINE 

DEFINE  RULE  ruleOSO 
::APPLIED.TO  I:INU 

::PRBNISB  aoni tor. speed. con t rol. for. bl4. and. up[ I)  and 
not  speed.control.for.bl4.and.up.go^[I] 

:: CONCLUSION  begin 

replace. faulty . coaponent ( I ] ; 
fault(I]  >  corresponding. gyro; 
end 

END.DEFINB 

I»FINE  RULE  rule051 
::APPLIBD.TO  I:INU 

::PRENISB  check.gyro.run.voltagefl J  and 
not  gyro.run.voltage.good(I] 

::CONCLUSION  interchange. psl. and. ps2(I] 

END.DEFINB 


■ 
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DBFUIB  rule  ruleOS2 
::APPUED.TO  I:IMU 

::PRBM1SE  interchange.psl.an<].ps2IIl  and 

problea . follows . power . supply . card [ 1 ] 

:: CONCLUSION  begin 

replace . faul ty . coaponent I I ] ; 
fault(I]  =  corresponding. power. supply. card; 
end 

END. DEFINE 

DEFINE  RULE  rule053 
::APPUED.TO  I:INU 

::PREMISE  interchange. psl. and. ps2(I]  and 

not  problea . follows . power . supply . card [ I ] 

:: CONCLUSION  begin 

replace . f aul ty . coaponen t ( I ] ; 
fault[I]  a  corresponding. gyro; 
end 

END. DEFINE 

DEFINE  RULE  ruleOS4 
:: APPLIED. TO  I:INU 

::PREHISB  check. gyro. circuit[I]  and 

not  speed. control. signal. good[I] 

: :CONCLUSION  in terchange. speed. control. cardsj I] 

END. DEFINE 

DEFINE  RULE  rule055 
::APPLIED.TO  I:IHU 

::PREHISE  interchange. speed. control. cardsfl)  and 

not  problea. follows . speed . control . card ( I ] 

:: CONCLUSION  begin 

replace . f aul ty . coaponent [ I ] ; 
fault[I]  =  cor responding. gyro; 
end 

END. DEFINE 

DEFINE  RULE  rule056 
::APPLIED.TO  I:INU 

::PREMISE  interchange. speed. control. cardsll]  and 

problea . follows . speed . control . card [ I ] 

:: CONCLUSION  begin 

replace. faulty . coaponent [ I ] ; 
fault! I]  a  corresponding. speed. card; 
end 

END. DEFINE 

DEFINE  RULE  ruleOS? 

:: APPLIED. TO  I:INU 
::PREHISE  run. next. test[I|  and 

not  next. test. good! I] 

::CONCLUSION  check.speed.stability!!] 

END.ISFINE 
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DEFINE  RULE  nileOSS 
::APPLIED.TO  I:INU 
t:PRENISE  run. next. test[I]  and 
next . tes t . good ( I 1 
::CONCLUSION  run.scorsby.test[I] 

END. DEFINE 

DEFINE  RULE  rule059 
:: APPLIED. TO  I:IMU 
::PREHISE  mn.scorsby. te8t[I]  and 

not  scorsby.goodll] 

::CONCLUSION  check. speed. stabilityll] 

END. DEFINE 

DEFINE  RULE  rule060 
::APPLIED.TO  I:IMU 
::PREMISE  mn.scorsby. test [I]  and 

scorsby.goodll] 

::C(»ICLUS10N  begin 

action[I]  =  "Testing  is  conplete.  All  inputs  indicate 
this  testing  is  good"; 
faultll]  =  none; 
end 

END. DEFINE 

/****ir**1c***1r*****iHr*1Ht*********1t*****1c**1t1rk***1t*******1t***1t**it*1t*1rk****/ 

/*  This  group  of  rules  includes  rules  061  -  064  and  corresponds  to  an  */ 
/*  inu  najor  error  Message.  This  section  also  uses  the  Check  Gyro  */ 
f*  Circuit  Routine  vhich  starts  with  rule  043.  */ 

DEFINE  RULE  mle06l 
:: APPLIED. TO  I:IKU 

::PREHISE  er ror. Message! I |  is  ieu. Major  and 

not  previous.lau.aajor[I| 

::C0NCLUSI0N  check. gyro. circuit[I] 

END. DEFINE 

DEFINE  RULE  mle062 
::APPLIED.T0  I:INU 

::PREHISB  error.nessage[I]  is  inu. Major  and 

previous . inu . aaj or I I I 
::C0NCLUSI0N  check. speed. stabilityll] 

END. DEFINE 

DEFINE  RULE  mle063 
:: APPLIED. TO  I: INU 

::PRBMISE  check.speed.stability|I]  and 

yz .  speed .  con  t  rol .  s  table  1 1  ] 

:: CONCLUSION  begin 

replace . f aul ty . conponen t | I ] ; 
fault|I]  -  displacenent. gyroscope. xy; 
end 

END. DEFINE 
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ISFINB  RULE  rule064 
::APPLIEO.TO  I:IMU 

::PRBMISB  check. speed. stabllity|I]  and 
not  yz. speed. control. stable[l] 

: : CONCLUSION  begin 

replace . f aul ty . coaponen  t ( I ] ; 
fault[I]  =  displaceaent. gyroscope. yz; 
end 

END. DEFINE 


*/ 
*/ 
*/ 
*/ 

IKFINE  RULE  rule065 
::APPLIED.TO  I:IMU 

::PREMISE  error.aessage[I]  is  in  (autoutic. shutdown, 

pvr. interrupt}  and 
operator . ini tiated . shutdown[ I ] 

: tCONCLUSION  noraal. response. to. operator. action[I] 

END. DEFINE 

DEFINE  RULE  rule066 
:: APPLIED. TO  I:IHU 

: : PREHI SE  noraal . response . to . operator . ac t ion [ I ] 

:  :CCWCLUSION  begin 

action(I]°”The  error  aessage  received  is  a  noraal 

response  to  an  operator  action.  No  action 
is  necessary”  ; 
fault [I]  «  none; 
end 

END. DEFINE 

DEFINE  RULE  rule067 
::APPLIED.TO  I:IHU 

::PREMISE  error. aessage[I]  is  in  (autoaatic. shutdown, 

pwr. interrupt)  and 
not  operator. ini tiated. shutdown{ I] 

::CONCLUSIW  atteapt.  restart  [I] 

END. DEFINE 


/*  This  group  of  rules  includes  rules  065  -  071  and  corresponds  to  the 
/*  following  error  aessages: 

/*  autoaatic. shutdown, 

/*  pwr . interrupt . 


iniFINE  RULE  rule068 
::APPLIED.T0  I:INU 
::PREHISE  atteapt. restart[I]  and 

not  restart. possible(II 
: :C0NCLUSI0N  check. power . cube( I ] 

END. DEFINE 


KFIMB  RULE  rule069 
:t APPLIED. TO  I:IMU 
::PREMISE  atteBpt.restart[I]  and 
restart . possible! 1 ] 

::CONCLUSION  action[I]  «  "continue  testing.  If  problea  persists 

contact  the  shop  supervisor" 


END.DBFINE 


DEFINE  RULE  rule070 
:: APPLIED. TO  I:INU 
:: PREMISE  check. power. cubef I]  and 

power . cube . good ( I I 
::CONCLUSION  contact. te(I] 

END.DBFINE 

DEFINE  RULE  rule071 
::APPLIED.TO  I:IHU 
::PREHISB  check. power. cube( I]  and 

not  power. cube. good! I] 
t: CONCLUSION  begin 

replace . faul ty . coaponen t ! I ] ; 
fault !I]  E  power. cube; 
end 

END.DBFINE 


/*  This  group  of  rules  includes  rules  072  -  074  and  corresponds  to  the  */ 
/*  following  error  aessages:  */ 
/*  i.c. fault  */ 


DEFINE  RULE  nile072 
::APPLIED.T0  I:IMU 

::PRENISB  error.aessage!!]  is  i.c. fault 

: :C0NCLUSI0N  check. cables! I ] 

END.DBFINE 

WFINB  RULE  nile073 
::APPUBD.T0  I:INU 
:: PREMISE  check. cables! I]  and 

cables. good! I I 

::C0NCLUSI0N  see. shop. supervisor!! | 
END.DBFINE 


KFINE  RULE  rule074 
::APPLIED.TO  I:INU 
::PRENISE  check. cables!Il  and 
not  cables. good! I] 

:: CONCLUSION  begin 

replace. faulty . coaponen t ! I ) ; 
fault!I|  s  bad. cable; 
end 


END.DBFINE 


/*  This  group  of  rules  includes  rules  075  -  076  and  corresponds  to  the  */ 
/*  systea  in  free  run  error  aessage.  */ 


DBFINB  RULE  rule075 
::APPLIBD.T0  I:INU 

t:PREMISE  error.aessagell]  is  systea.in. free.run  and 
pover . was . in terrupted ( I I 

::C0NCLUSI0N  action[Il  =  "restore  power.  If  problea  persists, 

contact  the  shop  supervisor" 


END. DEFINE 


M 


» 


DEFINE  RULE  rule076 
::APPLIED.T0  I:INU 

::PREHISE  error.nessage[I]  is  systea.in.free.run  and 
not  pover.vas.interrupted[IJ 
::C0NCLUSI0N  see. shop. supervisor! I] 

END. DEFINE 

/****♦*♦************■♦*♦****•**♦*'****♦*♦♦**♦*♦************»♦*■*♦*♦**♦♦♦*♦**/ 
/*  This  group  of  rules  includes  rule  077  and  corresponds  to  plat  stab  *l 

/*  abort.  It  also  uses  the  Check  Gyro  Circuit  Routine  which  starts  */ 

/*  with  rule  043  */ 

DEFINE  RULE  rule077 
::APPLIED.T0  I:IHU 

::PRBHISB  error.aessage(I]  is  plat. stab. abort 

::C0IICLUSI0N  check.gyro.circuit[I] 

BND.DBFINE 

/*****«*******«****«*****«***«*******«*****★***«***«*★**«**★************/ 
/*  This  group  of  rules  includes  rules  078  -  085  and  corresponds  to  the  */ 

/*  following  error  aessages:  */ 

/*  xvB. precounter. fault,  */ 

/*  yvB. precounter. fault  */ 

WFINE  RULE  rule078 
::APPLIED.T0  I:INU 

::PRENISE  error.aessage[Il  is  xva. precounter. fault 

:: CONCLUSION  begin 

check. veloci ty . on . ncc ( I I ; 
suspect. valljxvelocity.aeter.x  ; 
end 

END. DEFINE 


DEFINE  RULE  rule079 
k-  :: APPLIED. TO  I:IHU 

::PREHISB  error.aessagell]  is  yva. precounter. fault 
: '.CONCLUSION  begin 

check.velocity.on.ncc]!];  suspect. vB[I]3cvelocity.Beter.y  ; 
end 

BND.DBFINE 
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ISFINB  RULE  nileOSO 
::APPLIED.TO  I:IMU 
::PRBHISB  check 


::CONCLUSION 

END.tKFINB 


check. velocity. on. nccll]  and 
veloci ty . on . ncc . is . zero I I 1 
check .digital. processor [ I | 


DEFINE  RULE  ruleOSl 
::APPLIED.TO  I:IHU 

::PRENISE  check. digital.processorfl]  and 

digi tal . processor. good ( I ) 

::CONCLUSION  contact. te(I] 

END. DEFINE 

WFINB  RULE  rule082 
::APPLIED.TO  I:INU 

::PREMISE  check.digi tal. processor [I |  and 

not  d igi tal. processor. good[ I] 

:: CONCLUSION  begin 

action(I]  »  "Continue  testing.  The  fault  was  in  the 
digital  processor”; 
fault[I]  >  none; 
end 

END. DEFINE 

DEFINE  RULE  rule083 
::APPLIED.TO  I:INU 

::PREMISE  check. velocity. on. nccf 11  and 


:  .'CONCLUSION 
END. DEFINE 


check. velocity. on. nccfl]  and 
not  velocity.on.ncc.is.zero[I] 
check . va. signal . on . ncc ( I ] 


DEFINE  RULE  ruleOB4 
:: APPLIED. TO  I:IHU 

::PREMISE  check. va. signal. on. ncc[I]  and 

va . s ignal . on . ncc . good [ I 1 
::CONCLUSION  aove. to.aode.bll] 

BND.MFINE 

DEFINE  RULE  ruleOSS 
::APPLIED.TO  I:IHU 

::PREHISE  check. va. signal. on. ncc(I]  and 

not  va. signal. on. ncc. good[I] 
::CONCLUSION  begin 

replace. faul ty . coaponent I 1 ] ; 
faultfl]  >  suspect.vall] ; 
end 

END. DEFINE 
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/*1tk*****************it***********iHHHt*********iHr*1Ht***1Ht1t********1t1rk1t***/ 


/*  This  group  of  rules  includes 

rules  066  -  092  and  corresponds 

to  the  */ 

/*  following  error  messages: 

*/ 

/* 

x.gyro. torque. fault , 

*/ 

/* 

y . gyro . torque . faul t , 

*/ 

/* 

z . gyro . torque . faul t 

*/ 

DEFINE  RULE  rule086 
::APPLIED.TO  I:IMU 

::PREHISE  error.Bessage[I]  is  in  (x.gyro. torque. fault, 

y. gyro. torque. fault, 

z .  gyro . torque . faul t ) 

: : CONCLUSION  replace . digi tal . processor [ 1 ] 

END. DEFINE 

IffiFINB  RULE  rule087 
::APPLIED.TO  I:INU 

::PRENISE  replace. digi tal. processor|I]  and 

nev. digi tal . processor . corrects . problem [ I ] 

:: CONCLUSION  begin 

actionfl]  «  "Continue  testing.  The  fault  was  in  the 
digital  processor”; 
fault(I]  =  none; 
end 

END. DEFINE 

DEFINE  RULE  rule088 
t:APPLIED.TO  I:INU 

t:PRENISE  replace. digi tal. processorfl]  and 

not  nev. digi tal . processor . corrects . problem [ I ] 

: : CONCLUSION  check. gyro . torquers ( I ] 

END. DEFINE 

DEFINE  RULE  rule089 
:: APPLIED. TO  I:INU 

::PREHISE  check.gyro. torquers|I|  and 

gyro . torquers . s ignals . good ( I ] 

::CONCLUSION  see. shop. supervisor [I | 

END. DEFINE 

DEFINE  RULE  rule090 
::APPUED.TO  I:IHU 

::PRENISE  check.gyro. torquers( I)  and 

not  gyro. torquers. signals.goodi I] 

: rCONCLUSION  check.precision.current.netvorkfl] 

END. DEFINE 


I 


■ 


DEFINE  RULE  rule091 
i:APPUED.TO  I:IHU 

::PRBNISB  check. precision. current. iietvork[I]  and 

not  precision. current. network. good[I] 

: tCONCLUSION  begin 

replace . f aul ty . coaponen  t ( I ] ; 

£ault[I]  >  precision. current. network; 
end 

END. DEFINE 

DEFINE  RULE  rule092 
::APPLIED.TO  I:IHU 

::PREMISE  check. precision. current. network[I]  and 

precision. current .network. goodll ] 

::CONCLUSION  see. shop. supervisor [I] 

END.I»FINE 

/♦*****'iHHt*********************»*»**********'*********jHr****»************/ 

/*  This  group  of  rules  includes  rules  093  -  094  and  corresponds  to  the  */ 
/*  gyro  cold  error  aessage.  */ 

DEFINE  RULE  rule093 
:: APPLIED. TO  I:INU 

::PREHISB  error.aessage[I]  is  gyro. cold  and 

sys tea . achieved . gyro . noraal [ I ] 

::C0NCLUSI0N  aove. to.aode.b(II 
END. DEFINE 

DEFINE  RULE  rule094 
::APPL1BD.T0  I:IMU 

::PRENISB  error.aessagefl]  is  gyro. cold  and 

not  systea. achieved. gyro. noraal[I] 

:: CONCLUSION  begin 

action[I]  =  "No  action  is  required.  This  aessage  is 

coaaon  during  the  first  20  to  30  ainutes  of 
testing  while  the  gyro  waras  up”  ; 
fault[Il  >  none; 
end 

END. DEFINE 

/Mt**************  »*»*»»»*  kliltirk******************************************/ 

/*  This  group  of  rules  Includes  rules  095  -  100  and  corresponds  to  the  */ 
/*  gyro  hot  error  aessage.  */ 

DEFINE  RULE  rule09S 
:: APPLIED. TO  I:INU 

::PREMISB  error.aessage(I]  is  gyro. hot  and 
not  cooling. hose. is. connected(I| 

:: CONCLUSION  begin 

action! II  '  "reconnect  the  cooling  hose  to  the  INU”; 
faultfl]  «  none; 
end 

END. DEFINE 


146 


I 


■ 


I 


KFINB  RULE  nile096 
::APPLIEO.TO  IrlHU 

::PRBM1SB  error.Bessage{I]  is  gyro. hot  and 

cooling . hose . is . connec ted [ I ] 
::CONCLUSION  check. eeter. ■2. position. 21(1] 

BMD.KFINB 

DEFINE  RULE  rule097 
•  •  AP9t  TRD  *rO  T  *  TMll 

::PREMISE  check.eeter. ■2. position. 21(1]  and 

not  position. 21. setting. is. nonal(I] 
::CONCLUSION  aove. to.aode.b]!] 

BHD.DBFINE 

DBFINB  RULE  rule098 
::APPLIBD.TO  I:IMU 

::PREMISB  check. eeter. a2. position. 21(1]  and 

posi t ion . 21 . set t ing . is . normal ( I ] 

: :CONCLUSION  check. eeter. a2. position. 11(1] 

END. DEFINE 


DEFINE  RULE  rule099 
::APPLIBD.TO  I:IMU 

::PREHISB  check.eeter.e2. position. 11(1]  and 

not  position. 11. setting. is. nomal(I] 

::CONCLUSION  action(I]  «  "return  to  Node  B  station  and  perform  test  B22. 

The  high  start  circuit  is  faulty” 


BHD.DBFINE 


DEFINE  RULE  rulelOO 
::APPLIED.TO  I:IMU 

::PRKNISE  check. eeter. a2. position. 11(1]  and 

posi tion. 11. setting. is. noraai(I] 

::CONCLUSION  action]!]  >  "return  to  Node  B  station  and  perform  test  B22. 

The  gyro  and  associated  circuitry  is 
suspected" 

END. DEFINE 


/***********************************************************************/ 
/*  This  group  of  rules  Includes  rules  101  -  107  and  corresponds  to  */ 
/*  system  not  properly  caged.  */ 


DEFINE  RULE  rulelOl 
::APPLIED.T0  I:IHU 
::PREHISE 
.•.•CONCLUSION 
BND.I»FINE 


error.aessage(I]  is  system. not. properly. caged 
check . a . t o . d . conver t er . no t . caged ( I ] 


► 


9 
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DBnNB  RULE  rulel02 
::APPLIBD.TO  I:IMU 

::PREMISB  check.a. to. ({.converter. not. caged[ I]  and 

one . axis . is . fur ther . froa. zero[ I ] 

: (CONCLUSION  replace. platfora. electric. switch[I] 

BND.OBFINB 

DEFINE  RULE  rulelOl 
cAFPLIEO.TO  I:INU 

: (PREMISE  che<Jt.a. to.d.converter.not.caged[I]  and 

not  one . axis . is . further . f roa. zero( I ] 

((CONCLUSION  BOve.to.aode.b(I] 

BND.IMBFINB 

DEFINE  RULE  rulel04 
cAPPLIED.TO  I:INU 

((PREMISE  replace. platfora. electric. svitch[I]  and 

svi tch . solves . probleB[I ] 

((OWCLUSION  begin 

fault . found . continue. testingl I ) ; 
fault(I]  «  platfora.electric.svitch; 
end 

END. DEFINE 

DEFINE  RULE  rulel05 
{(APPLIED. TO  I:INU 

((PREMISE  replace. platfora. electric. svitch[I]  and 

not  svi tch. solves. problea[ I] 

{ (CONCLUSION  interchange. electronic. control. aaps[I] 

END. DEFINE 

KFINE  RULE  rulel06 
((APPLIED.TO  KIMU 

{(PREMISE  Interchange. electronic. control. aBps[I]  and 

problea . follows . aapl I ) 

((CONCLUSION  b^in 

replace . f aul ty . coaponen t { I ] ; 
fault[I|  «  corresponding. electronic. control. an 
end 

BND.IKFINE 

DEFINE  RULE  rulelO? 

{(APPLIED.TO  I:IMU 

: (PREMISE  interchange. electronic.control.aBps[ I]  and 

not  problea. follows. aapl I] 

((CONCLUSION  begin 

replace. faulty. coaponentll] ; 
faultll]  a  giabal.cage.aap; 
end 


END. DEFINE 


/*  This  group  of  rules  includes  rules  108  -116  and  corresponds  to  zstab  *f 

OEFINB  RULE  rulelOS 
::APPUED.T0  I:IMU 

ttPRENISE  error.nessage[I]  is  z.stab 

: tCONCLUSION  check.a. to. d. converter. z.stab[ I] 

END. DEFINE 

DEFINE  RULE  rulel09 
::APPLIED.TO  I:IMU 

::PRENISB  check.a. to. d. converter. z.stabfl]  and 

nuaber.o£.axes.not.zero(I]  is  all 
: :C0NCLUSI0N  check. for. case. rotation! I] 

BND.DEPINE 

DEFINE  RULE  rulellO 
::APPLIED.TO  I:IHU 

::PREHISB  check. for. case. rotationfl]  and 

case . ro ta t i on . noraal I I 1 
::C0NCLUSI0N  aove. to.aode.b[I] 

BND.DEPINE 

DEFINE  RULE  rulelll 
::APPLIBD.TO  I:IHU 

::PRBNISE  check. for. case. rotation(I)  and 

not  case. rotat ion. nonaalll] 

: : CONCLUSION  begin 

replace. faulty. coaponentfl];  fault(I}  » 
corresponding. gyro ; 
end 

BND.DEPINE 


I»FINE  RULE  rulelll 
::APPLIBD.TO  1:INU 

::PRBNISE  check.a. to. d. converter. z.stab(Il  and 

nuaber.of .axes.not.zerofl]  is  one 
: :C0NCLUSI0N  Interchange. giabal. rate. aBps[I) 

END. DEFINE 

DEFINE  RULE  rulelll 
::APPLIED.TO  I:IHU 

::PREHISE  interchange. giabal. rate. aaps[I]  and 

problea. follovs.giabal .rate.aapll ] 

:: CONCLUSION  begin 

replace . f aul ty . coaponen  t ( I ] ; 
fault(I]  >  corresponding. giabal. rate. aap; 
end 

END.raPINE 


t 
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KFINE  RULE  nilellA 
t:APPLIED.TO  I:IMU 

::PREM1SE  interchange. giabal. rate. aaps[Il  and 

not  problea . follows .giabal . rate . aap [ I ] 

: :CONCLUSI(X(  exchange. electronic. control. aapsll] 

BlfD.I»FINB 

DEFINE  RULE  rulellS 
:: APPLIED. TO  I:IMU 

::PREMISE  exchange.electronic. control. aapsll]  and 

problea . follows . aap ( I ] 

:  -.CONCLUSION  begin 

replace . f aul ty . coaponen  t ( I ] ; 

fault(I|  s  corresponding.electronic. control. aap; 
end 

END. DEFINE 

DEFINE  RULE  rulell6 
::APPUED.TO  I:IMU 

::PREHISE  exchange. electronic. control. aaps(I ]  and 

not  problea. follows.aapl I] 

::CONCLUSION  aove. to.aode.b[I] 

END. DEFINE 

/**********  ****»**»»  *★★»★★*★**★*♦******★****»*****»***********★********* / 
/*  This  group  of  rules  includes  rules  117  -  127  and  corresponds  to  */ 
/*  servo  disable.  */ 

DEFINE  RULE  rulell7 
::APPLIBD.TO  I:IHU 

::PREHISE  error.aessage(I|  is  servo. disable 

: :CONCLUSION  check. a. to. d. converter. servo. disable]!] 

END. DEFINE 

DEFINE  RULE  rulellE 
::APPLIED.TO  I:INU 

::PRENISE  check. a. to. d. converter. servo. disable]!]  and 

all . three. axes . near . zero] I ] 

: -.CONCLUSION  check,  test,  point.  23]  I] 

END. DEFINE 


MFINE  RULE  nilell9 
.-.-APPLIED.TO  I:INU 
:.- PREMISE 


:: CONCLUSION 
END. DEFINE 


check. a. to. d. converter. servo. disable]!]  and 
not  all. three. axes. near. zero]I] 
in terchange . ra te . aaps ] I ] 
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DEFINE  RULE  rulel20 
::APPLIBD.TO  I:1HU 

::PREIfISB  interchange. rate. aapsf I)  and 

not  problen. follows. board|I] 

:: CONCLUSION  nove. to.Bode.b{I] 

END. DEFINE 

DEFINE  RULE  rulel21 
::APPLIBD.TO  I:IMU 

::PRENISB  interchange. rate. anps[ I]  and 

problen . follows . board  f I j 
::CONCLUSI(X<  begin 

replace. faul ty . conponent | I ] ; 

f aul t ( I J  =cor respond i ng . ginbal .rate. elec  t  ron i c . con  t  r ol . anp ; 
end 

END. DEFINE 

DEFINE  RULE  rulel22 
:: APPLIED. TO  I:1MU 

::PREN1SB  check. test. point. 23(11  and 

power . supply . 4 . 8kh2 . good [ I 1 
.•{CONCLUSION  check,  test. point. 13(1] 

END. DEFINE 

DEFINE  RULE  rulel23 
: {APPLIED. TO  I{INU 

{{PREMISE  check. test. point. 23(1]  and 

not  power.supply.4.8khz.good(I] 

{ {CONCLUSION  replace.4.8.khz.power.supply(I j 
END. DEFINE 

DEFINE  RULE  rulel24 
{{APPLIED.TO  I{IHU 

{{PREMISE  replace.4.8.khz.power.supply(I]  and 

replacing. power . supply .solved . problen] I ] 

{{CONCLUSION  begin 

fault . found . continue. testing] I ] ; 
fault(I]  «  power. supply. 4. 8khz; 
end 

END. DEFINE 

KFINE  RULE  rulel25 
{{APPLIED.TO  I{INU 

{{PREMISE  replace.4.8.khz.power.supply(I]  and 

not  replacing. power . supply . solved . problen] I ] 

{{CONCLUSION  nove. to.node.b(I] 

END. DEFINE 


DEFINE  RULE  rulel26 
::APPLIED.TO  1:IMU 

::F1tEHISE  check. test. point. 13[I]  and 
power . supply . 400hz . good I I 1 

::CONCLUSION  action[I]s’'This  appears  to  be  a  intereittent  problee. 

Recoaaend  the  IMU  be  returned  to  Mode  B  and  the 
slip  rings  be  inspected" 

END. DEFINE 

DEFINE  RULE  rulel27 
.♦.•APPLIED.TO  I:IMU 

::PREMISE  check. test. point. 13[I I  and 

not  power. supply. AOOhz.goodI I] 

::CONCLUSION  action(I]2"Replace  or  troubleshoot  the  400hz  boards" 
END.raPINE 

/1Ht***1t1t**1Hfk1Hriflt****1Hi*1HHi1Ht***1rk1fk1fk*********1t**************1t1t********/ 

/*  This  group  of  rules  includes  rules  126  -  134  and  corresponds  to  */ 
/*  excess  angle  */ 

DEFINE  RULE  rulel28 
::APPLIBD.TO  I:IHU 

::PREMISE  error.aessage(I]  is  excess. angle  and  not 
ieu . in . caged . node ( I ] 

: iCONCLUSION  not. indication.of .£ault[I] 

END. DEFINE 

DEFINE  RULE  rulel29 
:: APPLIED.TO  I: IMU 

::PREMISE  error.eessagefl]  is  excess. angle  and 
iau . in . caged . Mode ( I ] 

::CONCLUSION  return. to. test (I ] 

END. DEFINE 

DEFINE  RULE  rulel30 
:: APPLIED. TO  I: IMU 
::PREMISE  return. to. test[Il  and 
not  able. to.restart[I] 

::CONCLUSION  aove. to.Bode.b[l] 

END. DEFINE 

DEFINE  RULE  rulel31 
::APPLIED.TO  I:INU 
::PRENISB  return. to. test(I]  and 
able. to. restart [I] 

::CONCLUSION  aonitor.pickoffsll] 

END. DEFINE 

DEFINE  RULE  rulel32 
:: APPLIED.TO  I: IMU 
:: PREMISE  Bonitor.pickoffsll]  and 

angle. occurs. first. on(I)  is  xy.pickoff 
::CONCLUSION  replace. ar8( I] 

END. DEFINE 


r 


r: 


DEFINE  RULE  rulel33 
::APPLIED.TO  I:IMU 
:: PREMISE  ■onitor.picko££s[I|  and 

angle. occurs. £irst.onlI]  is  yz.picko££ 
: tCONCLUSlON  replace. ar8[ I ] 

END. DEFINE 

DEFINE  RULE  rulel34 
:: APPLIED. TO  I;IHU 
::PRENISE  replace. ar8[ I)  and 

replacing . ar8 . helps  f 1 ] 

::C(X(CLUSION  begin 

£aul t . f ound . con t inue . tes t ing ( I ) ; 
£ault[I]  =  platlora.signal.aap; 
end 

END. DEFINE 


DEFINE  RULE  rule 135 
: -.APPLIED. TO  I:INU 
:: PREMISE  replace. ar8(l]  and 

not  replacing. ar8.helps(I]  and 
angle. occurs. £irst.on[I|  is  xy.pickoff 
::CONCLUSION  action(I]=  "Return  to  Mode  B  station.  The  XT  gyro  may  be 

£aulty" 


END. DEFINE 


DEFINE  RULE  rulel36 
-.-.APPLIED.TO  I:INU 
::PRENISE  replace. ar8l I]  and 

not  replacing. ar8.helps( I]  and 
angle. occurs. £irst.on(lj  is  yz.picko££ 

::CONCLUSION  action(I]°  "Return  to  Mode  B  station.  The  JZ  gyro  aay  be 

faulty" 


END. DEFINE 


/**♦**********************■***********************************♦*****♦**★**/ 
/*  This  group  of  rules  includes  rules  137  -  142  and  corresponds  to  RMS  */ 
/*  out  of  spec.  This  is  not  an  error  aessage,  but  is  an  important  */ 

/*  condition  that  requires  diagnosis.  */ 


DEFINE  RULE  rulel37 
:: APPLIED.TO  I:INU 
:: PREMISE 


: -.CONCLUSION 
END. DEFINE 


error.aessage{I]  is  ras. out. of .spec  and 
change(I|  is  sudden . change 
veloci ty . ae ter . i s . suspec t ( I ] 
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DEFINE  RULE  nilel38 
::APPLIBO.TO  I:INU 

::PRBNISB  error. Message! I]  is  ras. out. of .spec  and 

changell]  is  gradual. drift 
::CONCLUSI(W  gyro.is.suspectll] 

END. DEFINE 


DEFINE  RULE  rulel39 
::APPLIED.TO  I:IHU 


:: PREMISE 
:: CONCLUSION 
END. DEFINE 


velocity. aeter. is. suspect(I]  and 
aost.drif t[I]  is  longitude 

action(I]  «  "The  T  velocity  aeter  is  suspected  as  the  cause 
of  the  problea" 


DEFINE  RULE  rulel40 
::APPLIED.TO  I:IHU 

::PREMISE  veloci ty. aeter. is. suspect{I]  and 

aost.drift(II  is  lattitude 

::CONCLUSION  action[I|  =  "The  X  velocity  aeter  is  suspected  as  the  cause 

of  the  problea" 


END. DEFINE 


DEFINE  RULE  rulel41 
:: APPLIED. TO  I:IMU 
::?REMISE  gyro.is.suspect[I]  and 

aost.drift(I]  is  longitude 

t:CONCLUSION  action(I]  »  "The  XT  gyro  is  suspected  as  the  cause  of  the 

problea" 


END. DEFINE 


DEFINE  RULE  rulel42 
:: APPLIED. TO  I:IHU 
:: PREMISE  gyro.is.suspect[I)  and 

aost.drif t(I]  is  lattitude 


::CONCLUS10N  actionll] 
END. DEFINE 


"The  TZ  gyro  is  suspected  as  the  cause  of  the 
problea" 


f 
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/*  */ 

/*  Part  II:  Deep  Reasoning  Diagnostics  */ 

/*  ILt  Jia  Skinner  */ 

/*  21  Aug  88  */ 

/*  */ 


/*  This  portion  of  the  prograa  uses  a  aodel-based  approach  to  diagnose  */ 
/*  faults  in  the  Inertial  Measureaent  Unit  (IMU)  of  the  Dual  Miniature  */ 
/*  Inertial  Navigation  Systea.  Only  a  subset  of  the  IMU  is  diagnosed  */ 
/*  in  this  prograa.  This  subset  includes  the  velocity  aeter  function,  */ 
/*  the  gyro  speed  control  function,  and  the  gyro  torquing  function.  */ 
/*  */ 
Z***********************************************************************/ 


DEFINE  CONTROL. BLOCK  DIAGNOSE. IMU. FAULT 

:: INVOCATION  internal 

: '.ARGUMENTS  I:iau 

: :TRANSLATION  "deteraine  the  fault  in  the"! 

"IMU" 

::BOOT  begin  vars  dtduaay, 
high:path, 
aed:path, 
lov:path; 

create. instance  duaay  called  d  with 
naae.of(d]  ^''nul"; 

create. instance  path  called  high  with 
search. level (high]  ^  high. level; 
create. instance  path  called  aed  vith 
search. level (aed I  «  aed. level; 
create. instance  path  called  lov  vith 
search. levelllov]  «  lov. level; 
deteraine  error.aessage[I] ; 

if  error.aessage[I]  is  in  (velocity. unreasonable, 

vt. greater. than. 2. knots, 
xy . speed . con t rol , 
y z . speed . con t rol } 

then  invoke  deep.diagnose(I,I,d,high) 

else  display  nev.lineO  !  "This  error  aessage  has  not  been  "! 
"included  in  the  aodel." 

end; 

END. DEFINE 


I 
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/*  IXBP  DIAGNOSE  */ 

/*  This  Control  Block  is  the  Inference  Engine  of  this  portion  of  the  */ 
/*  progran.  Although  it  is  based  on  a  prograa  froa  the  S.l  aanual,  it  */ 
/*  is  greatly  enhanced.  The  control  block  determines  the  fault  of  the  */ 
/*  system  by  searching  for  a  bad  input  to  the  current  system.  If  one  is  */ 
/*  found,  the  control  block  is  called  with  the  component  responsible  for*/ 


/*  the  bad  input  as  its  argument.  This  continues  until  a  component  is  */ 
/*  found  with  a  bad  output,  but  no  bad  inputs.  It  is  then  determined  if  */ 
/*  this  component  has  subcomponents.  If  so,  the  subcomponents  are  built  */ 
/*  and  the  subcomponents  are  diagnosed.  When  a  component  is  found  with  */ 
/*  a  bad  output,  good  inputs,  and  no  subcomponents,  the  component  is  */ 
/*  identified  as  the  faulty  component  and  the  search  is  terminated.  The  */ 
/*  algorithm  has  been  enhanced  to  ensure  hipest  risk  components  (the  */ 
/*  components  most  likely  to  be  at  fault)  are  tested  first  followed  */ 
/*  by  components  with  medium  risk,  then  those  with  low  risk.  In  the  */ 
/*  case  of  components  with  multiple  inputs,  the  high  risk  inputs  will  */ 
/*  be  tested  first.  This  is  due  to  the  ordering  of  the  Rules  that  cause  */ 
/*  the  components  to  be  tested.  The  Arguments  for  this  control  block  */ 
/*  are:  */ 
/*  Component  -  The  component  currently  under  consideration.  */ 
/*  Start  -  The  first  component  in  the  current  path  being  tested.  */ 
/*  Finish  -  The  last  component  in  the  current  path  being  tested.  */ 
/*  (Initially,  a  dummy  variable  since  the  end  is  not  known)  */ 
/*  P:Path  -  ^e  level  of  the  current  search.  This  dictates  whether  a  */ 
/*  component  will  be  tested  immediately.  Initially,  the  */ 
/*  search  level  of  the  path  will  be  set  to  high  level  and  */ 
/*  only  components  with  high  risk  or  multiple  inputs  will  be  */ 
/*  tested.  If  the  fault  is  not  found,  the  search  level  will  */ 
/*  be  lowered  to  medium  level,  then  finally  low  level.  */ 


DEFINE  CONTROL. BLOCK  IXBEP. DIAGNOSE 

:: INVOCATION  internal 

::ARGUNENTS  COMPONENT: imu. component, 

START: imu. component , 

FINISH : imu . component , 
p:path 

::BODT 

begin 

display  new.line()! 

new.lineQ!  "Deep  Diagnose  was  invoked  with”! 
new.line()!  "component  »  "I  instance. trans( component ) ! 
new.lineOI  "start  >  "I  instance. trans(start)  I 
new.lineO!  "finish  =  "! instance.  trans( finish) ! 
new.lineOI  "level  «  "I  search. level(pj; 
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Case  search. level(pl  of 
high. level: 

/*  In  a  hi|^  level  search  end  will  always  equal  0  because  as  soon  as  an 
end  point  is  found,  level  of  search  will  be  changed  to  aediua.  Also,  the 
output  of  start  is  always  bad.  A  critical  test  coaponent  is  defined  as 
one  that  is  high  risk,  or  has  aultiple  inputs.  The  pseudo  code  for  high 
level  is: 

if  not  critical. test(coaponent)  and  not  end.point(coaponent) 
then  call  deep  diagnose(coaponentl, start, 0, high) 

if  not  critical. test(coaponent)  and  end. point (coaponent) 
then  call  deep. diagnose(start, start, coaponent, aed) 

if  critical. test(coaponent)  and  output. test. ok( coaponent) 
then  call  deep. diagnose(start, start, coaponent, aed) 

if  critical. test (coaponent)  and  not  output. test. ok(conponent) 
then  deteraine  bad. input (coaponent] 

if  bad. input  exists  call 

deep . diagnose ( coaponen  1 1 , coaponen  tl,0,high) 

if  bad. input  does  not  exist  deteraine  if  coaponent 

has  subcoaponents.  If  so,  call 

deep . d i agnose ( coaponen t 2 , coaponen t 2 , 0 , h i gh ) 

if  coaponent  does  not  have  subcoaponents  create 

instance  fault  with  naae. of (coaponent] .  */ 

begin 

deteraine  critical. test (COMPONENT]; 
if  not  critical. test(C0NP0NENT] 
then  begin 

if  end. point (COMPONENT] 
then  begin 

if  exists(ned:path|search.level[ned]  is 
aed. level) 

then  invoke  deep. diagnose(start, start, coaponent, aed) 
end 

else  begin 

if  exists(C0NP0NENTl:iau. coaponent, 

high : path | connected . to(C0NP0NENTl , COMPONENT ]  known 
and  search. level(high]  is  high. level) 
then  invoke  deep. diagnose(coaponentl, start, finish, high) 
«.ad 

end 

else  begin 

deteraine  output . test .ok [ coaponent ] ; 
if  output. test. ok(conponent] 
then  begin 

if  exists(ned: path  I  search. level [aed]  is  aed. level) 
then  invoke  deep. diagnose(start, start, coaponent, a^) 
end 
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else  begin 

detenine  bad. input ( COMPONENT 
if  bad. input [COMPONENT]  definite 
then  begin 

if  exists(CONPONENTl:iBu.coBponent,high:path| 
connected. tolOMPONENTl, COMPONENT]  > 
bad. input  I COMPONENT]  and 
search. level [high]  is  high. level) 
then  invoke  deep. diagnose(coBponentl,coBponentl, finish, high) 
end 

else  begin 

if  has. subcoaponent] COMPONENT] 
then  begin 

invoke  build . subcoaponent (COMPONENT) ; 
if  exists  (C0MP0NENT2:iBU.coaponent, 
high :  pa  th ,  d :  duai^  I 

saae .  ou  t  pu  t .  as  [  COMPtWENT ,  CONP(XIENT2  ] 
and  search. level [high]  is  high. level) 
then  begin 

invoke  deep . diagnose(C0MP0NENT2 , C0NP0NENT2 , d , high) ; 
end 

end 

else  display  nev.lineO!  "The  fault  vas  found”! 

"  to  be  the  "  !  instance. naae(COHPONENT) ; 

end; 

end; 

end; 

end; 
aed. level: 

/*  There  are  tvo  ways  aed  is  called  froa  the  high  level. 

First,  if  the  end. point  is  found  so  that  the  fault  has  been 
isolated  betveen  either  start  and  end. point  or  a  high  and  an 
endpoint.  Second  if  it  has  been  isolated  betveen  tvo 
endpoints.  Either  vay,  a  start  and  an  end  are  knovn.  Also, 
the  output  of  start  is  knovn  to  be  bad.  End  is  never  0.  There 
vill  be  no  high  risk  or  aultiple  input  coaponents  in  the 
path.  */ 

/*  if  risk(coaponent)  is  lov  and  not  coaponent  end  then 
call  deep  diagnose( coaponent 1,5 tart, end, aed)  */ 

/*  if  risk( coaponent)  is  lov  and  coaponent  «  end  then 
call  deep  diagnose(start, start, end, lov)  */ 

/*  if  risk( coaponent)  is  aed  and  output. test. ok(coBponent) 
then  call  deep. diagnose(start, start, coaponent, lov)  */ 

/*  if  risk( coaponent)  is  aed  and  not  output. test. ok(coaponent) 
then  deteraine  bad. input [coaponent]  */ 

/*  if  bad. input  exists  call 


158 


deep. diagnose(coaponentl , coaponentl , 0 , Bed)*/ 


/*  if  bad. input  does  not  exist  deteraine  if  component 
has  subcoaponents.  If  so»  call 
deep . diagnoseC  coaponen  1 2 , coaponen  t2 , 0 , high )  */ 

/*  if  component  does  not  have  subcoaponents  create 
instance  fault  with  naae.of(coBponent].  */ 


begin 

if  risk[ component  1  is  lov 
then  begin 

if  finish  »  component 
then  begin 

if  exists (lov: path I  search. level [lov]  is  lov. level) 
then  invoke  deep. diagnose(start, start, finish, lov) 
end 

else  begin 

if  exists(COMPONBNTl:iBU.coaponent,Bed:path| 
connected. to [COMPONBNTl, COMPONENT]  knovn  and 
search. level [aed]  is  aed. level) 
then  invoke  deep. diagnose(coBponentl, start, finish, aed) 
end 

end 

else  if  output. test. ok[COMPONENT] 
then  begin 

if  exists(lov: path  I  search. level[ lov]  is  lov. level) 
then  invoke  deep. diagnose(start, start, coaponent, lov) 
end 

else  begin 

determine  bad.input(COHPmENT); 
if  bad. input [COMPONENT)  definite 
then  begin 

if  exists(COHPONENTl:iBU. coaponent, d:duBBy, 

aed: path  I  connected. to[CONPONENri, COMPONENT]  - 
bad. input [COMPONENT]  and  search. level [aed] 
is  aed. level) 

then  invoke  deep. diagnose(coBponentl, component!, d, aed) 
end 

else  begin 

if  has. subcomponent [COMPONENT] 
then  begin 

invoke  build. subcoBponent(COMPONENT); 
if  exists  (C0NP0NENT2:iBU. component, 
d : duaay , high : pa th I 

saae . ou tpu t . as [ COMPONENT , C0NP0NENT2 ] 
and  search. level [high]  is  high. level) 
then  invoke 

deep.diagnose(C0HP0NENr2 ,C0MP0NENT2 ,d , high) 

end 

else  display  nev.line()!  "The  fault  vas  found”! 

”  to  be  the  ”  I  instance. naae(COMPONENT); 
end 
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end 

end; 


lov. level: 

/*  risk  is  known  to  be  low.*/ 

/*  input  known  to  be  single.*/ 

/*  the  output  is  bad  */ 

/*  if  bad. input  exists  call 
deep . diagnose( conponen 1 1 , coaponen 1 1 , 0 , low)  */ 

/*  if  bad. input  does  not  exist  determine  if  coaponent 
has  subcomponents.  If  so,  call 
deep. diagnose(conponfsnt2,coaponent2,0, high)  */ 

/*  if  component  does  not  have  subcomponents  create 
instance  fault  with  name. of [coaponent] .  */ 

begin 

determine  bad. input [COMPONENT]; 
if  bad.input(COHPONENT]  definite 
then  begin 

if  existsCCOMPONBNTl: imu. component, lov:path| 
connected. to[COMPONENTl, COMPONENT]  . 
bad.input[CONPONEIfT]  and  search. level] lov]  is 
lov. level) 

then  invoke  deep. diagnose(conponentl,conponentl, finish, lov) 
end 

else  begin 

if  has. subcomponent [COMPONENT] 
then  begin 

invoke  build. subcomponent (COMPONENT); 
if  exists  (C0NP0NENT2:iau. coaponent, d:duany, 

hi^ :  pa th  I  sane .  ou  t  pu  t .  as  I  COMPONENT ,  (X>MP(WENT2  ] 
and  search. level [high]  is  high. level) 
then  invoke  deep. diagnose(CONPONENT2,CONPONENT2,d, high) 
end 

else  display  nev.line()I  '^e  fault  was  found”! 

”  to  be  the  ”  !  instance. nane(CONPONENT); 

end 

end 

end; 

end; 

END.  DEFINE 
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/*  This  control  block  directs  the  prograa  to  the  correct  control  block  */ 
/*  for  constructing  the  subcoaponents  of  a  coaponent  for  further  */ 
/*  diagnosis.  */ 


DEFINE  CONTROL. BLOCK 
::INVOCATI(N< 
::ARGimEirrS 
: :TRANSLATION 

::BODT 


BUILD. SUBCOMPONENT 
internal 

COMPONENT : i au . coaponen t 

"build  the  logical  subcoaponent”! 

"of  the  systea" 


begin 

vars  Itiau, 

GTF:gyro. torque. function, 

GSCFO : gyro . speed . con t rol . func t i on . ou t put , 

GSCFE : gyro . speed . con t rol . func t ion . error , 

VMP : veloci ty . ae ter . func t ion ; 

case  naae. of [COMPONENT]  of 
"IMU":  begin 

if  exists  I:IMU 

then  invoke  build. iBu(I); 

end; 

"gyro  torquing":  begin 

if  exists  GTF:gyro. torque. function 

then  invoke  build. gyro. torque. function(GTF); 

end; 

"gyro  speed":  begin 

if  exists 

GSCFO : gyro . s peed . con t rol . func t i on . ou t pu t 

then  invoke  build. speed. control. output(GSCFO); 

end; 

"speed  error":  begin  if  exists 

GSCFE : gyro . speed . con t rol . func t i on . error 
then  invoke  build. speed. error(GSCFE); 
end; 

"velocity":  begin  if  exists  VMF: veloci ty.aeter. function 
then  invoke  build.velocity.function(VNF); 
end 
end; 
end; 

END. DEFINE 
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DEFINE  CONTROL.BLOCK  BUILD.IHU 

:: INVOCATION  internal 

::ARGUHENrS  I:IMU 

:: TRANSLATION  "build  the  logical  subcoaponent”! 

"of  the  aain  systea" 

::BODT 

begin 

vars  EHO:error.nessage.output, 

SIFT: sequence. tiaing. function. torque, 

STFR : sequence . t iaing . func t ion . run , 

FTF:platfom.  torquing.  function, 

GTF:gyro. torque. function, 

GSCFO : gyro . speed . con t rol . func t ion . ou t pu t , 

GSCFE: gyro. speed . control . function. error , 

VMF : veloc i ty . ae ter . func t ion ; 

display  nev.line()!  nev.line()!  "The  subcoaponents  of  the  IHU"I 
"  will  be  constructed."; 

create. instance  error. aessage. output  called  BHO  with 
begin 

saae. output. as(I,BMO] ; 
risk[EHOi  >  low; 
aultiple.  input(BffO| ; 

end; 

create. instance  velocity. aeter. function  called  VMF  vith 
begin 

has . subcoaponent ( VNF ] ; 
naae.oftVNF]  «  "velocity"; 
connected. to(VNF, END]  »  1; 
risk(VNF]  »  aed; 
end; 

create. instance  platfom.  torquing. function  called  RTF  vith 
begin 

naae.of[FTF]  «  "platfom"; 
connected. to (PTF,VHF]  =  1; 
risk[PTF]  -  lov; 
end; 

create. instance  gyro. speed. control. function. out put  called 
GSCFO  vith 
begin 

has. subcoaponent (GSCFO] ; 

naae. of (GSCFO]  =  "gyro  speed"; 

connected. to ( GSCFO, PTF]  ^  1; 

risk(GSCFO]  ^  high;  aultiple. input(GSCFO];  end; 


create. instance  gyro. speed. control. function. error  called  GSCFE 
vith 


begin 

has . subcoaponent [GSCFB] ; 
naae.of [GSCFB]  «  "speed  error”; 
connected. to[GSCFE,EMO]  =  2; 
risk(GSCFEl  -  high; 

■ultiple. input IGSCFE] ; 
end; 

create. instance  gyro. torque. function  called  GTP  with 
begin 

has . subcoaponent {GTP | ; 
nane.o£(GTFI  «  "gyro  torquing”; 
connected. to(GTF,GSCFE]  2; 
connected. to[GTP,GSCPOj  s  2; 
risk[GTPl  >  high; 
end; 

create. instance  sequence. tiaing. function. run  called  STPR  vith 
begin 

naae.of [STPR]  »  "sequence  tiaing  run"; 
connected. to[STPR,GSCPB]  =  1; 
connected. to[STPR,GSCPOj  >  1; 
risk(STPR]  *  low; 
end.pointfSTPR] ; 
end; 

create. instance  sequence. tiaing. function. torque  called  STPT  vith 
begin 

naae.of [STPT]  =  "sequence  tiaing  torque”; 
connected. to[STFr, GTP]  .  1; 
risk[STFT]  »  low; 
end. point [STPT]; 
end; 


end; 

BND.DBPINB 
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/♦*************iHHt*********  *♦*♦*■»♦*■*****♦**************♦******♦♦******♦*/ 


■ 
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I 


DEFINE  CONTROL. BLOCK 
:: INVOCATION 
::ARGUNENTS 
: : TRANSLATION 

::BODT 
begin 

vars  T.E: test.equipaent, 

Z.VM:x.velocity.aeter, 

T.VM:y.velocity.Mter, 

P:pover. distribution, 

F : frequency . s  tandard ; 

display  nev.line()!  nev.line()!  "The  fault  has  been  isolated"! 
"  to  the  velocity  aeter  function.  The  subcoaponents  of  the"! 

"  velocity  aeter  function  vill  be  constructed."; 

create. instance  test.equipaent  called  T.E  with 
begin 

saae. output. asfVMF, T.E] ; 
risk[T.E]  =  low; 
aultiple. inputfT.E]; 
end; 

if  exists  PTF:platfora. torquing. function 
then  create. instance  x. velocity. aeter  called  Z.VN  with 
begin 

connected. to(Z.VM, T.E]  =  1; 
connected. toiPTF,Z.VH)  1; 
risk(Z.VN]  «  high; 
aultiple. input [Z.VN]; 
end; 

if  exists  FTF:platfora. torquing. function 
then  create. instance  y. velocity. aeter  called  T.VN  with 
begin 

connected.  tofT.VN, T.E]  2; 

connected. to (PTF, T.VN]  =  1; 
risk[T.VN]  «  high; 
aultiple. input [T.VN]; 
end; 

create. instance  frequency. standard  called  F  vith 
begin 

connected. to(F, Z.VN]  ^  2; 
connected. to(F, T.VN]  =  2; 
risk(F]  »  low; 
end. point [F] ; 
end; 


BUILD. VELOCITT. FimCTION 
internal 

VNF: veloci ty . aeter . func t ion 
"build  the  logical  subcoaponent"! 
"of  the  velocity  aeter  function" 


I 
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create. instance  power. distribution  called  P  with 
begin 

connected. to[P,Z.VM]  =  3; 
connected. to(P,T.VNi  =  3; 
risk(P]  =  low; 
end.point(P] | 
end; 
end; 

END. DEFINE 


/  ii1rk1rk*****1rk1Ht****1rk***1rk1c*********1rk1t**********1t*1rk****1t1t'k1tk**1t1t***1t**  f 


l«PINE  CONTROL. BLOCK 
•.•.INVOCATION 
::ARCUMENrs 
:  :TItAMSLATION 


BUILD. GIRO . TORQUE . FUNCTION 
Incernal 

GTF:gyro. torque. function 
"build  the  logical  subcoaponent"! 
"of  the  gyro  torque  function” 


::BODT 

begin 

vars  GT:gyro. torquer, 

TD: torque. driver, 

PCN: precision . current . network, 
GTFR: gyro . torquer . field . return; 


display  nev.lineOI  nev.line()!  "The  fault  has  been  isolated”! 
”  to  the  gyro  torque  function.  The  subcoaponents  of  the"! 

"  gyro  torque  function  will  be  constructed."; 


create. instance  gyro. torquer  called  GT  with 
begin 

saae. output. aslGTP, GT] ; 
rlsk(GT]  s  high; 

end; 


if  exists  STFTzsequence.tiaing. function. torque 

then  create. instance  torque. driver  called  TD  with 
begin 

connected. toITD,GT]  -  1; 
connected. to {STPT,TD1  =  2; 
risk{TDI  »  a^; 
aul t i pie . input [ TD 1 ; 
end; 


create. instance  precision. current. netvork  called  PCN  with 
begin 

connected. to(PCN,TD]  »  1; 
risk[PCN]  »  aed; 

end; 

create. instance  gyro. torquer. field. return  called  GTFR  with 
begin 

connected.  to[GTFR, PCN]  ==  1; 
risk[GTFR]  «  high; 
end . point I GTFR 1 ; 
end; 

end; 


BUD.  DEFINE 


/************************************************************************/ 


/*  This  control  block  is  used  if  an  xy  or  yz  speed  control  error  is  */ 
/*  received.  The  case  where  the  Gyro  Speed  Control  Function  is  */ 
/*  identified  as  faulty  by  tracing  the  signal  back  through  the  Platfora  */ 
/*  Torquing  Function  is  handled  in  the  control  block  labeled  Build  */ 
/*  Speed  Control  Output.  */ 


DEFINE  CONTROL. BLOCK 
:: INVOCATION 
:: ARGUMENTS 
: : TRANSLATION 

::BODT 
begin 

wars  DCzdc.aap, 

BPF : band . pass . f i 1 ter , 

GB : gy ro . buf f er . BCA , 

GX:xy. gyroscope, 

GT : yz . gyroscope , 

SR:slip.ring, 

PS : power . supply , 

DCRC:d.c. run. control; 

display  new.line()l  new.line()!  "The  fault  has  been  isolated”! 

”  to  the  gyro  speed  control  function.  The  subconponents  of  the"! 
”  gyro  speed  control  function  will  be  constructed.”; 

if  exists  STFR:sequence. tiaing. function. run 
then  create. instance  dc.aap  called  DC  with 
begin 

sane. output. as(GSF, DC] ; 
connected. to [STFR, DC]  =  2; 
risklDC]  =  low; 

■ultiple.inputlDC] ; 
end; 

create. instance  band. pass. filter  called  BPF  with 
begin 

connected. to [BPF, DC]  =  1; 
risk(BPF]  >  aed; 
end; 

create. instance  gyro. buf fer.eca  called  GB  with 
begin 

connected. to(GB, BPF]  =  1; 
risk[GB]  =  a^; 
end; 

if  exists(I: iauj  error.aessagefl]  is  xy. speed. control) 
then  if  exists  GTF:gyro. torque. function 

then  create. instance  xy. gyroscope  called  GK  with 
begin 

connected. to(GX,GB]  ^  1; 


BUILD. SPEED. ERROR 
internal 

GSF: gyro. speed . control . function . error 
"build  the  logical  subcoaponent”! 

”of  the  gyro  speed  control  function" 


connected. to{GTF,GZ]  =  2; 
rlsk(GX]  .  high; 

Multiple. input[GZ]; 
end; 


if  exists(I:iBu|  error. Message! I]  is  xy. speed. control) 
then  create. instance  slip. ring  called  SR  with 
begin 

connected. to[SR,GZ]  =  1; 
risk! SR]  -  lov; 
end; 

if  exists(I:inu|  error .Message!! |  is  yz. speed. control) 
then  if  exists  GTF:gyro. torque. function 

then  create. instance  yz. gyroscope  called  GT  with 
begin 

connected. to !GT,GB I  s  1; 
connected. to I GIF, GT]  s  2; 
risk!GTl  >  high; 

Multiple. input!GT| ; 
end; 

if  exists(I: iMu|  error . Message ! I ]  is  yz. speed. control) 
then  create. instance  slip. ring  called  SR  with 
begin 

connected,  to!  SR,  GT]  = 
risk] SR]  «  low; 
end; 

create. instance  pover. supply  called  PS  vith 
begin 

connected. to!PS, SR]  »  1; 
riskiPS]  =  lov; 
end; 

create. instance  d.c.nin. control  called  DCRC  vith 
begin 

connected.  to!DCRC, PS]  1; 
risk] DCRC]  =  lov; 
end. point  I DCRC] ; 
end; 

end; 


END. DEFINE 


c 


I 


r 


I 


I 


/ik1Hf1t************1rk*****************************************************/ 

/*  This  control  block  handles  constructing  the  subcoaponents  of  the  */ 
/*  Gyro  Speed  Control  Function  in  the  event  the  fault  has  been  traced  */ 
/*  froa  the  Platfora  Torquing  Function.  */ 

DEFINE  CONTROL. BLOCK 
:: INVOCATION 
::ARGUHENTS 
: : TRANSLATION 

::BODT 

begin  vars  DC:dc.aap, 

BPF: band. pass. filter, 

GB : gy ro . buf f er . ECA , 

GX : xy . gyroscope , 

GT : yz . gyroscope , 

G:gyroscope, 

SR:slip.ring, 

PS : power . supply , 

DCRC: d . c . run. control ; 

display  nev.line()!  nev.line()!  "The  fault  has  been  isolated"! 

"  to  the  gyro  speed  control  function.  The  subcoaponents  of  the”! 

"  gyro  speed  control  function  will  be  constructed.”; 

deteraine  bad.pickoff [GSP] ; 
if  bad.pickoff[GSP]  is  XT 
then  begin 

if  exists  GTF:gyro. torque. function 
then  create. instance  xy. gyroscope  called  GX  with 
begin 

saae. output. as(GSP,GX]; 
connected. to (GTF,GX]  2; 

risk(GXI  ^  high; 
aultiple. input (GX] ; 
end; 

create. instance  slip. ring  called  SR  with 
begin 

connected. to (SR, GX]  =  1; 
risk(SR]  =  low; 
end; 

end; 

if  bad.pickoff(GSF]  is  TZ 
then  begin 

if  exists  GTF:gyro. torque. function 
then  create. instance  yz. gyroscope  called  GT  with 
begin 

sane . output . as (GSF ,GT ] ; 
connected. to(GTF,GT]  »  2; 
risk(GT]  *  high; 
aultiple. input (GT] ; 
end; 


BUILD. SPEED. CONTROL. OUTPUT 
internal 

GSF : gy ro . s  peed . con  t  r ol . f unc  ti on. output 
"build  the  logical  subconponent"! 

"of  the  gyro  speed  control  function" 


169 


create. instance  slip. ring  called  SR  with 
begin 

connected. to[SRtGTl  «  1; 
risk[SR)  »  low; 
end; 

end; 

if  bad.pickoff [GSP]  not. known 
.then  begin 

if  exists  GTF:gyro. torque. function  then  create. instance 
gyroscope  called  G  with 
begin 

sane. output. asIGSFfGl; 
connected. toIGTF,Gl  =  2; 
riskfG]  «  high; 

Bultiple. input IGl ; 
end; 

create. instance  slip. ring  called  SR  with 
begin 

connected. to[SR,Gl  =  1; 
risk! SR]  =  low; 
end;  end; 

create. instance  power. supply  called  PS  with 
begin 

connected,  to  (PS,  SR]  1; 

risk(PS]  =  low; 
end; 

if  exists  STFR:sequence. timing. function. run 
then  create. instance  d.c. run. control  called  DCRC  with 
begin 

connected. to[DCRC, PS]  =  1; 
connected. to [STFR, DCRC]  =  2; 
risk[DCRC]  >  low; 
multiple. input [DCRC] ; 
end; 

create. instance  band. pass. filter  called  BPF  with 
begin 

connected. to (BPF, DCRC]  =  1; 
risk[BPF]  =  med; 
end; 

create. instance  gyro. buff er.eca  called  GB  with 
begin 

connected. to(GB, BPF]  =  1; 
risk[GB]  »  med; 
end. point [GB]; 
end; 

end; 

BHD. DEFINE 


/*  CLASS  TYPE  */ 

/*  This  prograa  contains  a  single  class  type,  IMU. COMPONENT.  All  of  the  */ 
/*  classes  are  of  *sOtype.  */ 

DEFINE  CLASS. TYPE  IMU. COMPONENT 

::CONTAINS  (iau, 

sequence. tiaing. function. run, 

sequence. tiaing. function. torque, 

platfora. torquing. function, 

gy ro . torque . func t ion , 

gyro . spe^ . control . function .output , 

gyro . speed . control . function . error , 

velocity.aeter.fimction, 

error . aessage .output, 

test.equipaent, 

x. velocity.aeter, 

y .  veloci ty . ae ter , 
power. distribution, 
f r equency . s tandar d , 
gyro. torquer, 

gyro . torquer . field .return, 

torque. driver, 

prec i s i on . cur ren  t . ne  t work , 

gyro. torquer . field. return, 

dc.aap, 

band . pass . filter , 
gyro . buf f er . eca , 
xy. gyroscope, 
yz. gyroscope, 
gyroscope, 
slip. ring, 
duaay, 

power. supply, 
d.c. run. control} 

:: CLASS. TYPE. TRANSLATION  ”an  IMU  coaponent” 

::PLimAL.CLASS. TYPE. TRANSLATION  ”the  IMU  coaponents” 

::BLAND.INSTANCE. TRANSLATION  "the  IMU  coaponent” 

END. DEFINE 
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I 
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/**************************1Ht***1r**1HHi***1t******************1i*****1t**1t***/ 

/*  CLASSES  */ 

/*  There  are  29  classes,  one  for  each  function  or  coaponent  of  the  INU.  */ 
/*  The  classes  are  listed  here  in  alphabetical  order.  */ 

DEFINE  CLASS  band. pass. filter 

: : NUMBER. INSTANCES  1 

:: ANNOUNCEMENT  nev.line<)!  "A  aodel  of  the  "! 

"band  pass  filter  was  created." 

:: CLASS. TRANSLATION  "the  band  pass  filter" 

:: PULL. INSTANCE. TRANSLATION  "the  band  pass  filter" 

:: PLURAL. CLASS. TRANSLATION  "the  band  pass  filter" 

:: BLAND. INSTANCE. TRANSLATION  "the  band  pass  filter" 

END. DEFINE 

DEFINE  CLASS  dc.aap 

: : NUMBER. INSTANCES  1 

:: ANNOUNCEMENT  nev.line()!"A  aodel  of  the  DC  aap"! 

"  was  created." 

:: CLASS. TRANSLATION  "the  DC  aap" 

::FULL.INSTANCE.TRANSLATION  "the  DC  aap" 

:: PLURAL. CLASS. TRANSLATION  "the  DC  aap" 

:: BLAND. INSTANCE. TRANSLATION  "the  DC  aap" 

END. DEFINE 

IXPINE  CLASS  d.c. run. control 

: : NUMBER. INSTANCES  1 

:: ANNOUNCEMENT  nev.line()!  "A  aodel  of  the  DC" I 

"  run  control  was  created." 

:: CLASS. TRANSLATION  "the  DC  run  control" 

::FULL.INSTANCE.TRANSLATION  "the  DC  run  control" 

:: PLURAL. CLASS. TRANSLATION  "the  DC  run  control" 

:: BLAND. INSTANCE. TRANSLATION  "the  DC  run  control" 

END. DEFINE 


DEFINE  CLASS 

:  .‘NUMBER.  INSTANCES 

: : CLASS. TRANSLATION 

:: FULL. INSTANCE . TRANSLATION 

EMD.I»FINB 

DEFINE  CLASS 

: : NUMBER. INSTANCES 

: : CLASS. TRANSLATION 

: : PULL. INSTANCE. TRANSLATION 

:: PLURAL . CLASS . TRANSLATION 

: : BLAND. INSTANCE. TRANSLATION 

END. DEFINE 


duaay 

1 

"a  duaay  coaponent" 

"a  duaay  coaponent" 

error . aessage . ou tpu t 
1 

"the  error  aessage  output" 
"the  error  aessage  output" 
"the  error  aessage  output" 
"the  error  aessage  output" 
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I 


DEFINE  CLASS 
:: NUMBER. INSTANCES 
:: ANNOUNCEMENT 


: :CLASS.TRANSLATION 
: : FULL. INSTANCE. TRANSLATION 
: : PLURAL. CLASS. TRANSLATION 
: : BLAND. INSTANCE. TRANSLATION 
END. DEFINE 


frequency . s  tandard 
1 

nev.lineO! 

"A  Model  of  the” I 
”  frequency  standard  was  created 
”the  frequency  standard” 

"the  frequency  standard” 

"the  frequency  standard" 

"the  frequency  standard" 


DEFINE  CLASS 
:: NUMBER. INSTANCES 
:: ANNOUNCEMENT 


: : CLASS. TRANSLATION 
: : FULL . INSTANCE . TRANSLATION 
:: PLURAL . CLASS . TRANSLATION 
: : BLAND. INSTANCE. TRANSLATION 
END. DEFINE 


gyro. buffer. eca 
1 

nev.lineO! 

"A  aodel  of  the  gyro  buffer  ECA"! 
"  was  created.” 

"the  gyro  buffer  ECA” 

"the  gyro  buffer  ECA” 

"the  gyro  buffer  ECA” 

"the  gyro  buffer  ECA” 


DEFINE  CLASS 
: : NUMBER. INSTANCES 
:: ANNOUNCEMENT 

t : CLASS . TRANSLATION 
: :FULL.INSTANCE.TRANSLATION 
: : PLURAL. CLASS .TRANSLATION 
: :BLAND. INSTANCE. TRANSLATION 
END. DEFINE 


gyroscope 

1 

nev.lineO!  "A  aodel  of  the  gyroscope” 
!"  vas  created." 

"the  gyroscope” 

"the  gyroscope" 

"the  gyroscope" 

"the  gyroscope” 


DEFINE  CLASS 
: : NUMBER. INSTANCES 
:  '.CLASS. TRANSLATION 
:  '.FULL.INSTANCE.TRANSLATION 
: : PLURAL. CLASS .TRANSLATION 
: : BLAND. INSTANCE . TRANSLATION 
END. DEFINE 


gyro . speed . control . funct ion . error 
1 

"the  gyro  speed  control  function” 
"the  gyro  speed  control  function” 
"the  gyro  speed  control  function" 
"the  gyro  speed  control  function” 


DEFINE  CLASS 
: : NUMBER. INSTANCES 
: '.ANNOUNCEMENT 

:  .'CLASS. TRANSLATION 
: : FULL.INSTANCE.TRANSLATION 
: : PLURAL. CLASS. TRANSLATION 
: : BLAND. INSTANCE. TRANSLATION 
END. DEFINE 


gyro . speed . control . function .output 
1 

nev.lineO!  "A  aodel  of  the  gyro  speed  ”! 
"control  function  vas  created.” 

"the  gyro  speed  control  function” 

"the  gyro  speed  control  function” 

"the  gyro  speed  control  function” 

"the  gyro  speed  control  function” 
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MPINE  CLASS 
:: HUMBER. INSTANCES 
:: ANNOUNCEMENT 


: : CLASS. TRANSLATION 
: : FULL. INSTANCE. TRANSLATION 
:: PLURAL . CLASS . TRANSLATION 
:: BLAND . INSTANCE . TRANSLATION 
■I  END.I«FINE 

DEFINE  CLASS 
:: NUMBER. INSTANCES 
:: ANNOUNCEMENT 

:  .'CLASS. TRANSLATION 
: : FULL. INSTANCE. TRANSLATION 
: : PLURAL. CLASS. TRANSLATION 
: :BLAND. INSTANCE. TRANSLATION 
END. DEFINE 


gyro. torque. function 
1 

nev.lineO! 

"A  Bodel  of  the  gyro  torque  function"! 
"  was  created." 

"the  gyro  torque  function" 

"the  gyro  torque  function" 

"the  gyro  torquing  function" 

"the  gyro  torquing  function" 


gyro.torquer 

1 

nev.lineO!  "A  aodel  of  the  gyro  "  ! 
"torquer  vas  created." 

"the  gyro  torquer" 

"the  gyro  torquer" 

"the  gyro  torquer" 

"the  gyro  torquer" 


K 


I 


DEFINE  CLASS 
: :NUMBER. INSTANCES 
:: ANNOUNCEMENT 


: : CLASS. TRANSLATION 
:  .'FULL.INSTANCB. TRANSLATION 
: : PLURAL. CLASS. TRANSLATION 
: :BLAND. INSTANCE. TRANSLATION 
END. DEFINE 


gyro . torquer .field . return 
1 

nev.lineO! 

"A  Bodel  of  the  gyro  torquer  "! 
"field  return  vas  created." 
"gyro  field  return" 

"the  gyro  torquer  field  return" 
"the  gyro  torquer  field  return" 
"the  gyro  torquer  field  return" 


DEFINE  CLASS 
:: NUMBER. INSTANCES 
:  .'CLASS.  TRANSLATION 
:  .'PULL.INSTANCB. TRANSLATION 
:  :PLURAL.CLASS.TRANSUTION 
: tBLAND. INSTANCE. TRANSLATION 
END. DEFINE 


path 

any 

"the  platfon  torquing  function" 
"a  path" 

"the  platfora  torquing  function" 
"the  platfom  torquing  function" 


DEFINE  CLASS 

.' : NUMBER.  INSTANCES 

: '.ANNOUNCEMENT 


: : CLASS. TRANSLATION 
: :FULL.INSTANCE. TRANSLATION 
:: PLURAL . CLASS . TRANSLATION 
: : BLAND. INSTANCE . TRANSLATION 
END. DEFINE 


plat fora. torquing. function 
1 


nev.lineO! 

"A  aodel  of  the  plat fora"! 

"  torquing  function  vas  created.’ 
"the  platfora  torquing  function" 
"the  platfora  torquing  function" 
"the  platfora  torquing  function" 
"the  platfora  torquing  function" 


I 


17A 


DEFINE  CLASS 
:: NUMBER. INSTANCES 
: zAMMOUNCBNEKT 


: :CLASS.TRANSLATI(X( 

: : PULL. INSTANCE. TRANSLATION 
: : PLURAL. CLASS. TRANSLATION 
: : BLAND. INSTANCE. TRANSLATION 
END.NBFINE 

l»FINB  CLASS 
: : NUMBER. INSTANCES 
:: ANNOUNCEMENT 

: : CLASS. TRANSLATION 
: : FULL. INSTANCE. TRANSLATION 
: : PLURAL. CLASS. TRANSLATION 
: : BLAND. INSTANCE . TRANSLATION 
END. DEFINE 


power. distribution 
1 

nev.lineOt 

"A  Model  of  the  power”! 

”  distribution  was  created.” 
”the  power  distribution” 

”the  power  distribution” 

”the  power  distribution” 

”the  power  distribution” 


power. supply 
1 

new.line()l  ”A  aodel  of  the”! 
”  power  supply  was  created.” 
”the  power  supply” 

”the  power  supply” 

”the  power  supply" 

"the  power  supply” 


DEFINE  CLASS 
:: NUMBER. INSTANCES 
:: ANNOUNCEMENT 


: :  CLASS.  TRANSUTION 
: : FULL. INSTANCE. TRANSLATION 
: : PLURAL. CLASS .TRANSLATION 
: :BLAm). INSTANCE. TRANSLATION 
END. DEFINE 

DEFINE  CLASS 

: : NUMBER. INSTANCES 

: : CLASS. TRANSLATION 

: : FULL. INSTANCE. TRANSLATION 

: :PLURAL.CLASS.TRANSLATION 

: :BLAMD. INSTANCE. TRANSLATION 

END.DEFINE 


prec i s i on . cur ren  t . ne  t wor k 
1 

new.lineO! 

”A  Model  of  the  precision”  ! 

”  current  network  was  created.” 
"the  precision  current  network” 
"the  precision  current  network” 
"the  precision  current  network" 
"the  precision  current  network” 


search 

1 

"the  search” 
"the  search” 
"the  search” 
"the  search” 


l»FINE  CLASS 
: : NUMBER. INSTANCES 
: : CLASS. TRANSLATION 
: : FULL. INSTANCE. TRANSLATION 

:: PLURAL . CLASS . TRANSLATION 
: :BLAND. INSTANCE. TRANSLATION 
END.DEFINE 


sequence. tiaing. function. run 
1 

"the  sequence  tining  function" 

"the  gyro  run  and  start  coanands” 

!”  froa  the  sequence  tining  function” 
”the  sequence  tining  function” 

"the  sequence  tiaing  function” 
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DEFINE  CLASS 
: :NUNBER. INSTANCES 
:: ANNOUNCEMENT 


: : CLASS. TRANSLATION 
: : FULL. INSTANCE .TRANSLATION 

:: PLURAL . CLASS . TRANSLATION 
:  ‘.BLAND. INSTANCE. TRANSLATION 
END. DEFINE 

I»FINE  CLASS 
: : NUMBER. INSTANCES 
:: ANNOUNCEMENT 

: : CLASS. TRANSLATION 
: : FULL. INSTANCE. TRANSLATION 
:: PLURAL . CLASS . TRANSLATION 
: :BLAND. INSTANCE. TRANSLATION 
END. DEFINE 

DEFINE  CLASS 
: : NUMBER. INSTANCES 
:: ANNOUNCEMENT 

:  ‘.CLASS. TRANSLATION 
: : FULL. INSTANCE. TRANSUTION 
:: PLURAL . CLASS . TRANSLATION 
: : BLAND. INSTANCE . TRANSLATION 
END. DEFINE 

DEFINE  CLASS 
: :NUNBER. INSTANCES 
:: ANNOUNCEMENT 

: t CLASS. TRANSLATION 
:: FULL. INSTANCE . TRANSLATION 
: : PLURAL. CLASS. TRANSLATION 
: : BLAND. INSTANCE. TRANSLATION 
END. DEFINE 

DEFINE  CLASS 
: : NUMBER. INSTANCES 
:: ANNOUNCEMENT 

: : CLASS. TRANSLATION 
: : FULL. INSTANCE. TRANSLATION 
: :PLURAL.CLASS.TRANSLAT1(W 
: :BLAND.INSTANCE. TRANSLATION 
END.DEFINE 


sequence. tiaing. function. torque 
1 

nev.line()l 

"A  Model  of  the  sequence  tiaing” 
f  "  torque  function  vas  created.' 
"the  sequence  tiaing  function" 
"the  torque  coaaands  froa  " 

! "sequence  tiaing  function" 

"the  sequence  tiaing  function" 
"the  sequence  tiaing  function” 


slip. ring 
1 

nev.lineOI  "A  aodel  of  the”! 
"  slip  ring  vas  created." 

"the  slip  ring" 

"the  slip  ring" 

"the  slip  ring" 

"the  slip  ring" 


test.equipaent 

1 

nev.lineOI  "A  aodel  of  the  test  "I 
"equipaent  vas  created." 

•the  test  equipaent" 

"the  test  equipaent" 

"the  test  equipaent" 

"the  test  equipaent" 


;orque. driver 

iev.line()!  "A  aodel  of  the  torque  driver"! 
'  vas  created." 

'the  torque  driver" 

'the  torque  driver" 

'the  torque  driver" 

'the  torque  driver" 


velocity. aeter. function 
1 

nev.line()!  "A  aodel  of  the  velocity  aeter 
"!  "function  vas  created." 

•the  velocity  aeter  function" 

"the  velocity  aeter  function" 

•the  velocity  aeter  function" 

"the  velocity  aeter  function" 
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DEFINE  CLASS 
: tNUHBBR. INSTANCES 
:: ANNOUNCEMENT 

:  '.CLASS. TRANSLATION 
: : FULL. INSTANCE. TRANSLATION 
: : PLURAL. CLASS. TRANSLATION 
: :BLAND. INSTANCE. TRANSLATION 
END. DEFINE 


X . velocl ty . ae ter 
1 

nev.line()I  "A  aodel  of  ”! 

"the  X  velocity  aeter  vas  created.” 
"the  X  velocity  aeter” 

"the  X  velocity  aeter" 

"the  X  velocity  aeters" 

"the  X  velocity  aeter" 


1«PINE  CLASS 
: : NUMBER. INSTANCES 
:: ANNOUNCEMENT 


: : CLASS. TRANSLATION 
: : FULL. INSTANCE. TRANSLATION 
: :PLURAL.CLASS.TRANSLATION 
: : BLAND. INSTANCE . TRANSLATION 
END. DEFINE 


xy. gyroscope 
1 

nev.line()f 

"A  aodel  of  the  XT  gyroscope” 
I”  vas  created." 

"the  XY  gyroscope" 

"the  XT  gyroscope" 

"the  XT  gyroscope" 

"the  XT  gyroscope" 


DEFINE  CLASS 
: : NUMBER. INSTANCES 
:: ANNOUNCEMENT 

: : CLASS. TRANSLATION 
: : FULL. INSTANCE. TRANSLATION 
: : PLURAL. CLASS. TRANSLATION 
: : BLAND. INSTANCE. TRANSLATION 
END. DEFINE 


y . veloci ty. aeter 
1 

nev.line()i  "A  aodel  of  "! 

"the  T  velocity  aeter  vas  created." 
"the  T  velocity  aeter" 

"the  T  velocity  aeter" 

"the  T  velocity  aeters" 

"the  T  velocity  aeter" 


DEFINE  CLASS 
:: NUMBER. INSTANCES 
:: ANNOUNCEMENT 

: : CLASS. TRANSLATION 
: : FULL. INSTANCE. TRANSLATION 
: :PLURAL.CLASS. TRANSLATION 
: : BLAND. INSTANCE. TRANSLATION 
END.1«FINE 


yz. gyroscope 
1 

nev.line<)l"A  aodel  of  the  TZ"I 
"  gyroscope  vas  created." 

"the  TZ  gyroscope" 

"the  TZ  gyroscope" 

"the  TZ  gyroscope" 

"the  TZ  gyroscope" 
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/* 

/* 


ATTRIBVTES 


*/ 

*/ 


I»FINB  ATTRIBUTE 
:: DEFINED. W 
:  :TYPE 

:: MULTI VALUED 
:: LEGAL. MEANS 
:: DETERMINATION. 
:  '.TRANSLATION 
END. DEFINE 

DEFINE  ATTRIBUTE 
::DEFINED.ON 
; :TTPE 

:: MULTIVALUED 
::  LEGAL.  MEANS 
:: LEGAL. VALUES 
: : DETERMINATION. 
:: PROMPT 
: : TRANSLATION 
END. DEFINE 

DEFINE  ATTRIBUTE 
::DBFINBD.ON 
::TTPR 

:: MULTIVALUED 
::  LEGAL.  MEANS 
:: DETERMINATION. 
: : TRANSLATION 
BND.IKFINE 

DEFINE  ATTRIBUTE 
::DBFINED.ON 

:;TTPB 

:: MULTIVALUED 
: : TRANSLATION 


END. DEFINE 

ISFINE  ATTRIBUTE 
::DEFINED.ON 
::TTPE 

:: MULTIVALUED 
:: LEGAL. MEANS 
:: DETERMINATION 
: : TRANSLATION 
END. DEFINE 


BAD.  INPUT 

CCWPONENT : isu. coaponent 

integer 

false 

(try. rules} 

MEANS  (try. rules) 

"the  bad  input" 


BAD.PICKOFF 

GSPO : gyro . speed . con t rol . func t i on . ou t pu t 

text 

false 

(query. user] 

(XT.TZ) 

MEANS  (query. user} 

"Which  gyro  picfcoff  is  bad?" 

"the  bad  pickoff" 


CIRCUIT. FAULT 
COMPONENT : iau . coaponen t 
text 
false 

(try. rules} 

MEANS  (try. rules) 

"the  fault  of  the  circuit" 


CONNECTED. TO 

CONPONENTl :  iau.  coaponent , 
CONPONENT2: iau. coaponent 
integer 
false 

instance. trans(COMPONENTl)  I 
"  is  connected  to  "  ! 
instance. trans(CONPONENT2) 


CRITICAL. TEST 
COMPONENT : iau . coaponen t 
boolean 
false 

(try. rules) 

MEANS  (try. rules} 

"the  test  is  critical" 
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I 


ISPINE  ATTRIBVTE 
tiDBFlllED.ON 
: :TTPB 

:: MULTIVALUED 
:: LEGAL. MEANS 
: : DETERMINATION . MEANS 
:  :TRANSLATI(»i 
END. DEFINE 


END. POINT 

COMPONENT : iau . coaponen  t 

boolean 

false 

(try. rules) 

(try. rules) 

"the  coaponent  is  an  endpoint" 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
::TTPE 

:: MULTIVALUED 
:: LEGAL. MEANS 
: :  DETERMINATION .  MEANS 
:: PROMPT 

: : TRANSLATION 
END. DEFINE 


ERROR.  SIGNAL 

gy r o . torque . func  t i on 

boolean 

false 

(query. user) 

(query. user) 

"Check  the  torque  current  error  signal." 

I"  Is  the  signal  good?" 

"the  torque  current  error  signal  is  good." 


DEFINE  ATTRIBUTE 
:: DEFINED. ON 
; ;TTPB 

:: MULTIVALUED 
:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
:  .'PROMPT 

: : TRANSLATION 
END. DEFINE 


GIRO. OUTPUT. OK 

gy ro . speed . con t rol . func t i on . ou t pu t 

boolean 

false 

(query. user) 

(query. user) 

"Check  the  gyro  pickoffs." 

I"  Are  the  signals  froa  the  gyros  ok?" 
"the  gyro  outputs  are  ok" 


DEFINE  ATTRIBUTE 
::DEFINED.ON 
: :TTPB 

:: MULTIVALUED 
: : TRANSLATION 


END.I«FINE 


HAS. SUBCOMPONENT 
COMPONENT : iau . coaponent 
boolean 
false 

instance. trans(COMPONENT)  I 
verb("  does  ",  "  does  not  ")  ! 
"  contain  subcoaponents  " 


DEFINE  ATTRIBUTE 
::ISFINED.ON 
::TTPE 

:: MULTIVALUED 
:: LEGAL. MEANS 
: : DETERMINATION. MEANS 
: '.PROMPT 
: : TRANSLATION 
END. DEFINE 


LEVEL. PLATFORM 

platfora. torquing. function 

boolean 

false 

(query. user) 

(query. user) 

"Is  the  platfora  level?” 
"the  platfora  is  level" 


li 


¥ 
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I»PINB  ATTRIBUTE 
:: DEFINED. ON 
; :TTPE 

:: MULTI VALUED 
END. DEFINE 

DEFINE  ATTRIBUTE 
:  .'DEFINED. ON 
: :TTPB 

:: MULTIVALUED 
: : TRANSLATION 
END. DEFINE 

DEFINE  ATTRIBUTE 
: '.DEFINED. ON 
: :TTPE 

:: MULTIVALUED 
:: LEGAL. MEANS 
:  '.DETERMINATION. 
:: PROMPT 

: : TRANSLATION 

END. DEFINE 

DEFINE  ATTRIBUTE 
::DBFINED.ON 
::TTPE 

:  .'LEGAL.  VALUES 
:: MULTIVALUED 
:: TRANSLATION 
END. DEFINE 

DEFINE  ATTRIBUTE 
::  DEFINED.  ON 
:  ;TTPB 
MULTIVALUED 
:: LEGAL. MEANS 
:: DETERMINATION 
:: PROMPT 

: : TRANSLATION 
END. DEFINE 

DEFINE  ATTRIBUTE 
:: DEFINED. ON 

:  :TTPB 

:: MULTIVALUED 
: : TRANSLATION 


MULTIPLE. INPUT 
COMPONENT : iau . coaponen t 
boolean 
false 


NAME. OF 

COMPONENT : imu . coaponen t 

text 

false 

"the  naae  of  a  circuit  coaponent” 


OUTPUT. TEST. OK 
COMPONENT: iau . coaponen  t 
boolean 
false 

{try. rules, query . user} 

MEANS  (try. rules, query. user} 

"Is  the  output  of  the  "! 
instance. trans(CONPONENT)  !  "  good?" 
instance. trans(CONPONBNT)  !  verb("  did  not  " 
"  did  ")  !  "fail  the  output  test" 


RISK 

COMPONENT : iau . coaponen  t 

text 

(lov,aed,high} 

false 

"the  risk  of  a  circuit  coaponent" 


RUN. COMMAND. OK 

sequence. tiaing. function,  nm 

boolean 

false 

(query. user} 

MEANS  (query. user} 

"Check  the  gyro  run  and  gyro  start  coaaands 
froa  the  NCC.  Are  the  signals  good?" 

"the  start  and  run  signals  are  good.” 


SANE. OUTPUT. AS 
COMPONENTl : iau . coaponen  t , 

COMPONENT! : iau . coaponent 

boolean 

false 

instance. trans(CONP(WENTl)  !  verb("  does  ", 
does  not  ")  !  "have  the  saae  output  as  "  ! 
Instance. trans(CONPONEHT2) 


END. DEFINE 


DEFINE  ATTRIBUTE 
::DBFINEO.ON 
; :TTPE 

:: LEGAL. VALUES 
: '.HULTIVALUBD 
: : TRANSLATION 
END.  DEFINE 

DEFINE  ATTRIBUTE 
::DEFINEO.ON 
: :TTPE 

:  .'MULTIVALUED 
END. DEFINE 

DEFINE  ATTRIBUTE 
::DEFINED.ON 
: :TTPE 

:: MULTIVALUED 
END. DEFINE 

DEFINE  ATTRIBUTE 
::DEFINED.ON 
: :TTPE 

:: MULTIVALUED 
:: LEGAL. MEANS 
:: DETERMINATION 
::PRONPT 

: : TRANSLATION 
END. DEFINE 


SEARCH. LEVEL 


path 

text 

( lov . level f  aed . level , . level ) 
false 

"the  level  of  the  search” 


TEST. LOV.RI SR. INPUTS 
COMPONENT: iau.coaponent 
boolean 
false 


TEST. MED.RI SR. INPUTS 
COMPONENT : i Bu . coaponen t 
boolean 
false 


TORQUE . COMMAND. OR 

sequence. tiaing. function. torque 

boolean 

false 

(query. user} 

MEANS  (query. user} 

"Check  the  torque  coaaands  froa  "t 
"the  NCC.  Are  the  signals  good?” 

"the  start  and  run  signals  are  good." 
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/* 

/* 


RULES 


*/ 

*/ 


/*  The  order  of  Rules  201,  202,  and  203  ensure  that  high  risk  inputs  */ 
/*  vill  be  tested  first,  then  aed  risk,  then  lov  risk.  */ 


DEFINE  RULE 
: :APPLIED.T0 
:: PREMISE 


:: CONCLUSION 
END. DEFINE 


RULE. 201 

COMPONENT: iau. coaponent 

already. existing(CONPONENTl:iau.coaponent  | 
deterained?( connected. to [CONPONENTl, COMPONENT |) 
and  connect^. to  (CMfPONENTl, COMPONENT]  known 
and  risk(COMPONENTl|  is  high 
and  output. test.ok(CONPONENTl]  thought. not) 
bad. input {COMPONENT)  . 

connected . to[C0NP0NENTl , COMPONENT ] ; 


DEFINE  RULE 
::APPLIED.TO 
:: PREMISE 


.•.•CONCLUSION 
END. DEFINE 


RULE. 202 

COMPONENT: iau. coaponent 

already. existing(C0NP0NEMTl:iau. coaponent  | 
de terained? (connected. to [CONPONENTl, COMPONENT ) ) 
and  connect^. to  [COMPONQITl, COMPONENT]  known 
and  risk] CONPONENTl]  is  aed 
and  output. test. okfCONPONENTl]  thought. not) 
bad.inputlCOMPMENTJ  « 

connected.  tolomPONENTl , COMPONENT] ; 


DEFINE  RULE 
: :APPLIED.TO 
::FRENISE 


:: CONCLUSION 
END. DEFINE 


RULE. 203 

COMPONENT: iau. coaponent 

already. existing(COMPONENTl: iau. coaponent  | 

de  terained? ( connec  ted . to ( CONPONENTl , COMPONENT ] ) 

and  connect^. to  [(XMPONENTl, COMPONENT]  known 

and  risk) CONPONENTl)  is  low 

and  output. test. ok(C0NP0NENTl]  thought. not) 

bad. input [COMPONENT)  . 

connec ted . to ( CONPONENTl , COMPONENT  ] ; 


f** **************** ******** »***♦**♦****»♦♦*»♦♦*★★***»***★♦*******»»**»»*/ 

/*  Rules  204  -  218  change  the  proapt  to  the  technician  to  a  aore  */ 

/*  aeaningful  proapt.  */ 


DEFINE  RULE 
::APPLIED.T0 
:: PREMISE 


::C0NCLUSI0M 

END.DBFINB 


RULE. 204 

velocity.aeter. function 
already . exis t ing( I : iau I 

error.aessage[I]  is  in  (velocity. unreasonable, 

vt. greater. than. 2. knots) ) 
ou t pu t . tes t . ok[ veloci ty . ae ter . f unc t ion ] <- 1 . 0> 


DEFINE  RULE 
::APPLIEO.TO 
::PRENISB 


::CONCLUSION 
END. DEFINE 

DEFINE  RULE 
: :APPLIED.TO 
::PREHISE 


: : CONCLUSION 
END. DEFINE 

IttFINE  RULE 
: :APPLIED.TO 
:: PREMISE 

: tCONCLUSION 
END. DEFINE 

DEFINE  RULE 
:: APPLIED. TO 
::PREHISE 

: tCONCLUSION 
END. DEFINE 

DEFINE  RULE 
ttAPPLIBD.TO 
::PREHISE 
: tCONCLUSION 
END. DEFINE 

DEFINE  RULE 
ttAPPLIED.TO 
ttPREMISE 
t tCONCLUSION 
END. DEFINE 

DEFINE  RULE 
ttAPPLIED.TO 
ttPREMISE 
t tCONCLUSION 
END. DEFINE 

DEFINE  RULE 
t  tAPPLIED.TO 
ttPREMISE 
t  tCONCLUSION 
EMD.DEFIME 


RULE. 205 

gyro . speed . control . f unc  t ion . error 
al ready . exls t ing( I : inu I 

error.Bessage[II  is  in  (velocity. unreasonable, 

vt. greater. than. 2. knots}) 
output . test .ok[gyro. speed. control. function. error  I 


RULE. 206 

velocity.aeter. function 
already . exis t ing( I t iau I 
error.aessage[Il  is  in  (xy. speed. control, 

yz . speed . con t rol } ) 

output. test. ok[ velocity.aeter. function] 


RULE. 207 

gyro . speed . control . function . error 
already . exist ing( I t iau I 
error.aessage]!]  is  xy. speed. control) 
output . test .ok [gyro. speed. control . function. error ] <-l .0> 


RULE. 208 

gyro. speed . control . function. error 
already . existing(I : iau | 
error.aessage(Il  is  yz. speed. control) 
output . test . ok[gyro . speed . control . function . error ) <-l . 0> 


RULE. 209 

platfom.  torquing.  function 

level .  pla  t  f  om  I  pla  t  f  ora .  torquing .  f  unc  t  ion  ] 

output. test .okiplatfora. torquing. function] 


RULE. 210 

platfora. torquing. function 

not  level. platfom]platfora. torquing. function] 
output. test. ok] platfora. torquing. function]<-1.0> 


RULE. 211 

gy ro . speed . con t rol . f unc t i on . ou t pu t 

gyro. output. ok] gyro. speed. control. function. output] 

ou t pu t . t es t . ok [ gyro . speed . con t ro 1 . f unc t i on . ou t pu t j 


RULE.212 

gy  ro .  speed .  con  t  rol .  f  unc  t  i  on .  ou  t  pu  t 
not  gyro. output. ok]gyro. speed. control. function. output] 
output . test .ok] gyro. speed. control. function. output ]<-l .0> 
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WFIMB  RULE 
: :APPLIBD.TO 
::PRBNISB 
: : CONCLUSION 
BND.DBFIlfB 


RULE. 213 

gyro. torque. function 

error .signal[gyro. torque. function] 

output . test .ok[gyro. torque. function] 


DEFINE  RULE 
:: APPLIED. TO 
::PREHISE 
: :CONCLUSION 
EM).  DEFINE 


RULE. 214 

gyro. torque. function 

not  error. signal [gyro. torque. function] 

ou t pu t . tes t . ok ( gyro . torque . func t i on ]<- 1 . 0> 


i»PINE  RULE 
::APPLIED.TO 
ttPREHISE 
: : CONCLUSION 
END. DEFINE 


RULE. 215 

sequence. tiaing. function. run 

run . coaaand . ok [ sequence . t iai ng . func t i on . run ] 

ou t pu t . tes t . ok [ sequence . t iai ng . func t i on . run ) 


DEFINE  RULE 
: :APPLIED.TO 
:: PREMISE 
: '.CONCLUSION 
END. DEFINE 


RULE. 216 

sequence. tiaing. function. run 

not  run. coaaand. ok[ sequence. tiaing. function. run] 
ou t pu t . tes t . ok [ sequence . t iai ng . func t ion . run ]<- 1 . 0> 


ISPINE  RULE 
::APPUED.TO 
:: PREMISE 
: : CONCLUSION 
END. DEFINE 


RULE. 217 

sequence. tiaing. function. torque 

torque. coaaand. ok [sequence. tiaing. function. torque] 
output . test .ok [sequence. tiaing. function. torque] 


DEFINE  RULE 
::APPLIED.TO 
:: PREMISE 
:: CONCLUSION 
END. DEFINE 


RULE. 218 

sequence. tiaing. function. torque 

not  torque. coaaand. ok[ sequence. tiaing. function. torque] 
ou  t pu t . tes  t . ok[ sequence .tiaing. func  t ion . torque ]<- 1 . 0> 


/*  Rule  300  and  301  define  a  critical  test  coaponent  as  one  that  is  */ 
/*  either  high  risk  or  has  aultiple  inputs.  A  critical  coaponent  oust  */ 
/*  be  tested  on  the  first  pass.  */ 


DEFINE  RULE 
:: APPLIED. TO 
:: PREMISE 
:: CONCLUSION 
END.DBFINE 


RULE. 300 

COMPONENT: iau. coaponent 
risk] coaponent]  is  high 
critical. test [coaponent] 


KFINE  RULE 
::APPLIED.T0 
::PREMISE 
::C0NCLUSI0N 
BND.KFINE 


RULE. 301 

COMPONENT : i au . coaponen t 
aultiple. input [ coaponent ] 
cri t ical . tes t [ coaponent ] 


/*  Kule  302  ensures  that  the  first  coaponent  In  the  subconponent  is  */ 
/*  narked  as  having  a  bad  output  to  prevent  the  systen  fron  needlessly  */ 
/*  pronpting  for  another  test.  */ 


DEFINE  RULE 
: :APPLIED.TO 
:: PREMISE 


: :C0NCLUSI0N 
END. DEFINE 


RULE. 302 

COMPONENT: inu. coaponent 

already . exis  t ingCCOMPONENTl : inu . conponen  t 

sane. output. as (COMPONENTl, COMPONENT]  and 

not  output. test. ok] COMPONENTl]) 

ou t pu t . tes t . ok ( conponen t ]<- 1 . 0> 
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